Deleting a preloaded image from memory
ivan....@gmail.com
say I preload an image by creating an Image object and setting its src
attribute to desired URL:
var img = new Image();
img.src = [someurl];
Then I use the image a few more times by adding it into an Array
object:
var images = new Array();
images.push(img);
I found out that just calling 'delete' on a pointer to that Image
object, doesn't free up the RAM.
delete images[0]; //RAM is not freed here!
Should I call delete on all the references to the image object? This
would be a real pain, since I have to check about 3000 lines of code
for possible references to it and make sure I 'delete' all of them...
What about the other new Image objects, that get their src attribute
set to the same url?
Bart Van der Donck
> How can I really delete a preloaded image from memory/disk cache? Let's
> say I preload an image by creating an Image object and setting its src
> attribute to desired URL:
>
> var img = new Image();
> img.src = [someurl];
img = null;
> Then I use the image a few more times by adding it into an Array
> object:
>
> var images = new Array();
> images.push(img);
>
> I found out that just calling 'delete' on a pointer to that Image
> object, doesn't free up the RAM.
>
> delete images[0]; //RAM is not freed here!
images = null;
> [...]
Hope this helps,
--
Bart
ivan....@gmail.com
from memory, but just change the address the pointer is referencing
(from address of the object to null = 0x0000000). The object might get
deleted if the memory is managed and a garbage collector finds out
there is no more reference to the object in question. However if any
other pointer is still referencing the same object, the memory manager
will keep it in memory. That's just how it works.
The solution you gave me is not just useless, but even less effective
than the one I wrote in the question myself. Any other ideas?
Bart Van der Donck
> Setting a pointer to null obviously won't delete the object pointed to
> from memory, but just change the address the pointer is referencing
> (from address of the object to null = 0x0000000). The object might get
> deleted if the memory is managed and a garbage collector finds out
> there is no more reference to the object in question. However if any
> other pointer is still referencing the same object, the memory manager
> will keep it in memory.
I've done some investigation about this issue. My way (setting to
'null') and your way (delete method) do not seem to free up any memory
of the objects (CPU benchmarks on MSIE and FF). My conclusion is that
there is no reliable way to do what you want. There's only one JScript
function:
CollectGarbage();
But that is (explicitly) undocumented and (explicitly) unofficial
though, and that usually has a good reason.
Some good references and quotes:
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/1d97e35c3a102831/:
"The problem is that you don't really have a way to know when the
garbage collector will free the memory. It is a task with low priority"
http://msdn.microsoft.com/msdnmag/issues/03/09/WebQA/default.aspx:
"Now, you can force the JScript garbage collector to run with the
CollectGarbage() method, but I don't recommend it. The whole point of
JScript having a GC is that you don't need to worry about object
lifetime. If you do worry about it then you're probably using the wrong
tool for the job!"
http://msdn.microsoft.com/msdnmag/issues/03/09/WebQA/default.aspx:
"JScript was designed to provide a quick, easy way to write simple
scripts on Web pages. The fact that you're asking at all makes me think
that you're using the wrong tool for the job."
"Yes, calling CollectGarbage() is wrong. It's undocumented for a
reason. It won't solve any of your problems."
--
Bart
ivan....@gmail.com
automatically in JavaScript, just as it does in Java, C# and other
'modern' languages. Its designed to 'ease' the memory handling. But the
more I think about my problem, the more I get the sense that it's
probably not really connected to garbage collector.
I think objects that get cached by a browser are handled on
another/higher level, than other "programmatical" objects, created by a
script. In fact we are speaking about two different kinds of memory
data - one is the data that is put in cache (image bytes, html text)
and the other is data of DOM programming objects (which make a language
'object oriented').
The programming objects are handled by a 'garbage collector' and are
freed after no pointer references them anymore. On the other side, the
cached data can still be left there (in cache) even after one closes
the browser application (that means in the 'disk cache' memory) in
order to make the rendering of the page faster next time in a short
period. The pure proof of this is that even when i close the browser
(and I see that RAM gets freed), the next time I open it and run the
same web application preloading the same images, they get 'loaded' in
an instance.
There should be (if they exist at all) some other functions not related
to garbage collector to manage the data that is cached. I know how to
explicitly make a page not being cached, by adding some special tags
into the html file. However this is not my preference, because I want
to be able to preload images when I need to, so I wonder: is there any
way to control (delete) the cached data once its cached?
ivan....@gmail.com
to achieve:
My application preloads images one after another when the user browses
a gallery, so there are always 10 images loaded in advance. These
images get shown immediately when the user reaches them, so she doesn't
have to wait.
Now when the user had already browsed over 100 of images, I would like
to delete some of them at the beginning of the 'playlist' and free the
memory so my application can run this way for hours.
How do I achieve this?
Bart Van der Donck
> To clarify my problem I will give an example of what I'm really trying
> to achieve:
>
> My application preloads images one after another when the user browses
> a gallery, so there are always 10 images loaded in advance. These
> images get shown immediately when the user reaches them, so she doesn't
> have to wait.
I think you're looking for a functionality like SQL's FLUSH or Perl's
buffer disable/clean on command. I don't believe this can be controlled
on-the-fly in browsers, though there are META-instructions to control
this on page-level:
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="Thu, 8 May 2006 11:30:00 GMT">
(or whatever date)
<META HTTP-EQUIV="pragma" CONTENT="no-cache">
> Now when the user had already browsed over 100 of images, I would like
> to delete some of them at the beginning of the 'playlist' and free the
> memory so my application can run this way for hours.
> How do I achieve this?
The whole idea is that a browser should do all this for you, so you
don't have to worry about it (ideally). I would advocate the use of
another computer language if you need this kind of low level memory
block access.
You could develop the gallery in Macromedia Flash, end let the SWF-file
handle its own memory objects (I believe this would stand apart from
the browser's memory allocation). I'm not sure if Flash/ActionScript
could go as low as influencing RAM on-the-fly. Maybe some Flash
Newsgroup could shed a light on this.
--
Bart
ivan....@gmail.com
making an extension.
Thomas 'PointedEars' Lahn
> Setting a pointer to null obviously won't delete the object pointed to
> from memory,
True, except of the "pointer" term. This is ECMAScript, not C; there are
references, not pointers.
The operation marks the object referred to for garbage collection, unless
there are other references to that object.
> but just change the address the pointer is referencing
> (from address of the object to null = 0x0000000).
Pure speculation.
PointedEars
--
Indiana Jones: The Name of God. Jehovah.
Professor Henry Jones: But in the Latin alphabet,
"Jehovah" begins with an "I".
Indiana Jones: J-...
Thomas 'PointedEars' Lahn
> The problem is I really need to achieve this in Firefox because I am
> making an extension.
There is no need for preloading in the first place.
PointedEars
Bart Van der Donck
I'm thinking in the same direction, yes.
To the original poster:
In stead of shoe-horning your way through browsers' internal memory
block allocation, why not use plain simple HTML code. It works for
everybody else's image galleries, so why not for you ? Sure, one could
say something for your preloading idea. The obvious benefit is that a
surfer doesn't need to wait for the new images. But the same actually
applies to any web page. Say you have a homepage with a language choice
English/Dutch, why wouldn't you already preload the next 2 pages ?
I think your scenario has more disadvantages than benefits. I'ld
counsel a plain HTML strategy if I were you.
--
Bart
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> ivan....@gmail.com wrote:
>> > The problem is I really need to achieve this in Firefox because I am
^^^^^^^
>> > making an extension.
^^^^^^^^^
>> There is no need for preloading in the first place.
>
> I'm thinking in the same direction, yes.
>
> To the original poster:
> In stead of shoe-horning your way through browsers' internal memory
> block allocation, why not use plain simple HTML code. It works for
> everybody else's image galleries, so why not for you ? Sure, one could
> say something for your preloading idea. The obvious benefit is that a
> surfer doesn't need to wait for the new images. But the same actually
> applies to any web page. Say you have a homepage with a language choice
> English/Dutch, why wouldn't you already preload the next 2 pages ?
>
> I think your scenario has more disadvantages than benefits. I'ld
> counsel a plain HTML strategy if I were you.
Full ACK for (X)HTML. The `link' element can facilitate preloading if
it is considered really necessary.
But: Am I missing something here, or wasn't a Firefox extension running
on the Gecko chrome, hence on _XUL_? I fail to find /any/ need for
preloading _local_ resources; computers are this fast. IMHO, preloading
is only for resources retrieved from the server, for later local use.
Especially, probably XUL has the means so that no Image object needs to
be used, that memory is freed when the object is no longer used and that
switching images works smoothly anyway.
PointedEars
--
Homer: I have changed the world. Now I know how it feels to be God!
Marge: Do you want turkey sausage or ham?
Homer: Thou shalt send me *two*, one of each kind.
(Santa's Little Helper [dog] and Snowball [cat] run away :))
Thomas 'PointedEars' Lahn
> How can I really delete a preloaded image from memory/disk cache?
You can _not_. You cannot even be sure that an image resource was cached.
And why would you want to do that anyway? The cache is not your business.
If the resource in the cache is outdated, use cache control headers to tell
the UA that this is the case. If it is not outdated, then why delete it?
Maybe you are confusing cache (file resource) and heap (memory resource).
Script objects are stored on the heap, not in the cache. Deleting an
object on the cache does not free heap memory and vice-versa.
> [...]
> delete images[0]; //RAM is not freed here!
Then there is probably another reference to that object. But, how are you
trying to determine "RAM" usage?
> Should I call delete on all the references to the image object?
No, you only need to `delete' those that are not defined local.
(You have to cared about scoping before? Tough luck.)
> What about the other new Image objects, that get their src attribute
> set to the same url?
The `src' _property_ does not matter here.
var img1 = new Image(); img1.src = "foo";
and
var img2 = new Image(); img2.src = "foo";
are still two different Image objects that require memory each. They maybe
use the same cached resource, that is all. That said, using different
Image objects for the same image resource is simply BAD -- Broken As
Designed.
PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Blanched Soldier"
Bart Van der Donck
> ivan....@gmail.com wrote:
> > but just change the address the pointer is referencing
> > (from address of the object to null = 0x0000000).
>
> Pure speculation.
That is no speculation - it's just how this works. The 0x0(0)(0)...
address is the null pointer by default. Its notation (e.g. 0x0000000)
just depends on 8, 16, 32, etc bit memory, but it always refers to null
as the "very first" pre-reserved memory address.
Setting a javascript variable to null is just re-referencing it from
its current block to the one that belongs to null. The browsers that I
tested do not compile this action with a pragma to empty the referenced
memory though (supposed the address is not used anywhere else anymore).
Yes, I was surprised about the results of my ealier CPU benchmarks in
MSIE&FF. I expected the memory addresses would be cleaned up quite fast
if there were no references to it anymore (even with low job priority).
--
Bart
Richard Cornford
>> ivan....@gmail.com wrote:
>>> but just change the address the pointer is referencing
>>> (from address of the object to null = 0x0000000).
>>
>> Pure speculation.
>
> That is no speculation - it's just how this works. The 0x0(0)(0)...
> address is the null pointer by default. Its notation (e.g. 0x0000000)
> just depends on 8, 16, 32, etc bit memory, but it always refers to
> null as the "very first" pre-reserved memory address.
>
> Setting a javascript variable to null is just re-referencing it from
<snip>
You appear to be confusing javascript with C or some other language.
Javascript has no 'pointer' data types, its Null value is a primitive
type (so does not even have to be a reference of any sort, just an
arbitrary internal value) and the mechanism employed internally is not
specified in the applicable language specification and almost certainly
is not consistent across implementations.
You are speculating, and even reading some open source implementations
and making statements about what they do is irrelevant to the issues of
javascript authoring as those observations could never be applied to
all language implementations.
Richard.
Bart Van der Donck
> ivan....@gmail.com wrote:
> > [...]
> > delete images[0]; //RAM is not freed here!
>
> Then there is probably another reference to that object.
The whole point of this discussion is that the object is fully
dereferenced, but the address itself still remains available internally
as a memory block.
> But, how are you trying to determine "RAM" usage?
On WinXP: CTRL-ALT-Delete > tab 'Processes' > 'Memory use'. On Unix,
see the 'top' command.
> > Should I call delete on all the references to the image object?
>
> No, you only need to `delete' those that are not defined local.
> (You have to cared about scoping before? Tough luck.)
There is a chance scoping could help, but frankly I don't think so
(haven't tested).
--
Bart
Bart Van der Donck
> [...]
> You appear to be confusing javascript with C or some other language.
I'm not talking about javascript code. I'm talking about how a browser
compiles javascript code.
> Javascript has no 'pointer' data types
Indeed, not at the high javascript code level - but it does at the
browser's low compile level. These are just general basic computer
mechanisms. Every variable points (or 'references' if you like) to a
memory block address. That isn't visible at the surface in javascript,
but is definitely how it works internally. Referencing and memory
allocation take place when the browser compiles the javascript to
something the machine understands. That's why it's so difficult to
influence memory handling from within javascript.
> its Null value is a primitive
No, 'null' is a well defined address (must be) and its reference is
somewhere between 0x000 and 0x0000000000000 (BTW, null is not a value,
it's the "not-value" that is defined that way by 0x0...).
> type (so does not even have to be a reference of any sort, just an
> arbitrary internal value) and the mechanism employed internally is not
> specified in the applicable language specification and almost certainly
> is not consistent across implementations.
Any computer language works with memory allocation/release and
(de)referencing to those.
> You are speculating,
No, I am not
> and even reading some open source implementations
> and making statements about what they do is irrelevant to the issues of
> javascript authoring as those observations could never be applied to
> all language implementations.
You're right - this discussion is irrelevant to javascript authoring
itself.
--
Bart
Richard Cornford
>
> > [...]
> > You appear to be confusing javascript with C or some other language.
>
> I'm not talking about javascript code. I'm talking about how
> a browser compiles javascript code.
Browsers are not the only software that executes javascript code, and
you don't know how it is done in 'a browser', or anywhere else, in
general. You can only examine how it is done in specific
implementations, and cannot validly generalise beyond that. When you
are thinking about this remember that there is at least one javascript
implementation written in javascript.
>> Javascript has no 'pointer' data types
>
> Indeed, not at the high javascript code level - but it does at the
> browser's low compile level.
Not necessarily. IceBrowser uses Rhino for its javascript engine, and
Rhino is written in Java, so has no pointers. If you insist on going
down through the layers you will end up at the machine code level,
where there are no 'pointers', only integers loaded into data and
address registers, etc.
> These are just general basic computer
> mechanisms. Every variable points (or 'references' if you like) to a
> memory block address.
A memory address, it is only conceptually a block when some (byte)
length information is also associated with the value.
> That isn't visible at the surface in javascript,
> but is definitely how it works internally.
Which may be no more useful a statement than observing that CPUs
execute machine code.
> Referencing and memory allocation take place when the
> browser compiles the javascript to
> something the machine understands.
Rhino does not compile javascript to something the machine understands,
it compiles it to something the JVM understands, and the JVM does the
next step.
> That's why it's so difficult to
> influence memory handling from within javascript.
The difficulty is because javascript uses automatic garbage collection,
which is not intended to be influenced by executing code.
>> its Null value is a primitive
>
> No, 'null' is a well defined address (must be)
No, in javascript Null (the value that is assigned with - x = null -)
is a primitive value, and may or may not have any association with a
memory address.
> and its reference is
> somewhere between 0x000 and 0x0000000000000
An address between zero and zero (not a very wide gap)?
> (BTW, null is not a value,
> it's the "not-value" that is defined that way by 0x0...).
Not in javascript. In javascript Null is a primitive type with a single
value. The nature of that value is not specified or important. It may
be entirely arbitrary, or borrowed from the implementation language.
>> type (so does not even have to be a reference of any sort, just an
>> arbitrary internal value) and the mechanism employed internally is not
>> specified in the applicable language specification and almost certainly
>> is not consistent across implementations.
>
> Any computer language works with memory allocation/release
> and (de)referencing to those.
Memory allocation is not part of machine code. The lowest level at
which memory allocation would be expected is at the level of the OS.
And once you get far enough up that the memory allocation has been
abstracted outside of your control it stops being part of the picture
again.
>> You are speculating,
>
> No, I am not
Oh yes you are. You just don't have access to the information necessary
to make these generalisations.
>> and even reading some open source implementations and
>> making statements about what they do is irrelevant to the issues of
>> javascript authoring as those observations could never be applied to
>> all language implementations.
>
> You're right - this discussion is irrelevant to javascript authoring
> itself.
So irrelevant to this group.
Richard.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> ivan....@gmail.com wrote:
>> > [...]
>> > delete images[0]; //RAM is not freed here!
>>
>> Then there is probably another reference to that object.
>
> The whole point of this discussion is that the object is fully
> dereferenced, but the address itself still remains available
> internally as a memory block.
The OP did write about other references to that object, see the citation
below.
BTW: You should look up the meaning of "(to) dereference".
>> But, how are you trying to determine "RAM" usage?
>
> On WinXP: CTRL-ALT-Delete > tab 'Processes' > 'Memory use'. On Unix,
> see the 'top' command.
Don't patronize me. That question was intentionally directed to the OP.
And the programs you mentioned (that I was well aware of) display only
memory usage of the _browser process_. Especially for Firefox, this does
not bear any meaning regarding memory usage of the script engine and
memory allocated for script objects, due to its known memory leaks.
>> > Should I call delete on all the references to the image object?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> No, you only need to `delete' those that are not defined local.
>> (You have to cared about scoping before? Tough luck.)
>
> There is a chance scoping could help, but frankly I don't think so
> (haven't tested).
Again you have no proof (not even the slightest hint in form of a test
result) for your wild assumptions at all but you insist on them. Although
regarding this question, it is very clear from the language specification
that a locally defined object reference ceases to exist once the execution
context is left (unless it is part of a closure). However, no more
references to an object means that the object is marked for garbage
collection. And the SpiderMonkey engine used by Firefox does not have
IE's "circular reference" problem.
PointedEars
--
This above all: To thine own self be true.
-- William Shakespeare (1564-1616)
Bart Van der Donck
> [...]
> >> You are speculating,
> >
> > No, I am not
>
> Oh yes you are. You just don't have access to the information necessary
> to make these generalisations.
Maybe this will convince you. Say the following javascript code:
var aVar;
That was the declaration. The computer reserves a name 'aVar' for
future use, but this name does not refer to a memory address yet at
this point.
aVar = 5;
That was the assignment. 5 is converted (to keep things simple) to
binary numerical data (the notation with 1's and 0's). Suppose each
memory block consists of 8 bits, then the value would become 00000101
in this case. Then 00000101 is allocated to an address, let's say we
name the address ABC. A programmer actually instructs the ABC-address
to remember the value 00000101 for him, in case he would need it later.
This memory allocation is a physical (electronical/magnetic) thing
inside the hardware of your PC.
The variable aVar then gets assigned to memory address ABC. If we
dereference aVar, we don't need name ABC anymore and we could free that
address (that is, if it was not used by something else anymore), and
thus gaining memory space to create new addresses.
In old computer languages like Assembler, this whole process would need
to be done manually. Each memory address was a series of (physical)
bulbs in a computer room. Each byte (corresponding to 8 bits in my
example) went on and off depending on the value it stored at that
moment. 1 is on and 0 is off - which is basically still the only thing
a computer knows (boolean values). I guess that's why early computers
were always associated by flikkering lamps.
Since a few decades, the jobs of the flikkering lamps were taken over
by minimal chipsets in stead of bulbs, today they're even 0,001
millimeter chips or so in stead of 1 meter of bulbs. Thus the term
micro-computing and even the company MicroSoft (=software for computers
with micro-chips).
--
Bart
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> [...]
>> You appear to be confusing javascript with C or some other language.
>
> I'm not talking about javascript code. I'm talking about how a browser
> compiles javascript code.
A (Web) browser does not compile "javascript" code. ECMAScript conforming
code is either compiled or interpreted, or both, by the script engine of an
execution environment (which can be a Web browser, and is in most cases).
SpiderMonkey, which is the script engine of the JavaScript reference
implementation used in Firefox, is known to compile source code to
bytecode that is interpreted by a virtual machine. SpiderMonkey itself
is written in C.
>> its Null value is a primitive
>
> No, 'null' is a well defined address
It is not. You are confusing languages and concepts, as Richard said.
> (must be)
I does not need to at all.
> and its reference is somewhere between 0x000 and 0x0000000000000
It does not have to be.
> (BTW, null is not a value, it's the "not-value" that is defined that way
> by 0x0...).
Nonsense. Read the ECMAScript Language Specification. `null' is a
primitive value, the sole value of the Null type, which is an object type.
It may be represented in compiled code by any value that is not used
otherwise. In that regard it is not different to the (IEEE-754) NaN and
infinities values, which are primitive values as well, of the Number type,
in ECMAScript implementations.
>> You are speculating,
>
> No, I am not
Yes, you are.
>> and even reading some open source implementations
>> and making statements about what they do is irrelevant to the issues of
>> javascript authoring as those observations could never be applied to
>> all language implementations.
>
> You're right - this discussion is irrelevant to javascript authoring
> itself.
Oh dear. You have not even understood that there are different ECMAScript
language implementations (JavaScript, JScript, Opera-ECMAScript, KJS), and
(therefore) different script engines. Where the ECMAScript Language
Specification makes exactly no statement on how the `null' value SHOULD
or MUST be represented in implementation code. And that is good so.
PointedEars
--
There are two possibilities: Either we are alone in the
universe or we are not. Both are equally terrifying.
-- Arthur C. Clarke
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> [...]
>> >> You are speculating,
>> > No, I am not
>> Oh yes you are. You just don't have access to the information necessary
>> to make these generalisations.
>
> Maybe this will convince you. Say the following javascript code:
>
> var aVar;
>
> That was the declaration. The computer reserves a name 'aVar' for
> future use, but this name does not refer to a memory address yet at
> this point.
That is questionable, since aVar is initialized to `undefined', the sole
value of the Undefined type, which is another of the built-in ECMAScript
object types, by that statement (see ECMAScript Language Specification,
Edition 3 Final, 12.2 Variable statement).
Once again, I strongly recommend to you to read the language specification
before you post further bold statements about how you /think/ things work.
For I presume nobody here needs another VK.
> [...]
> Since a few decades, the jobs of the flikkering lamps were taken over
> by minimal chipsets in stead of bulbs, today they're even 0,001
> millimeter chips or so in stead of 1 meter of bulbs. Thus the term
> micro-computing and even the company MicroSoft (=software for computers
> with micro-chips).
You don't say!
Score adjusted
PointedEars
--
Multiple exclamation marks are a sure sign of a diseased mind.
-- Terry Pratchett
Bart Van der Donck
> Bart Van der Donck wrote:
> > That was the declaration. The computer reserves a name 'aVar' for
> > future use, but this name does not refer to a memory address yet at
> > this point.
>
> That is questionable, since aVar is initialized to `undefined', the sole
> value of the Undefined type, which is another of the built-in ECMAScript
> object types, by that statement (see ECMAScript Language Specification,
> Edition 3 Final, 12.2 Variable statement).
That would be possible, yes. Traditionally, the declaration only
reserves the name without assigning any value to it.
Maybe javascript has another logic here (what would be the difference
between executing 'var aVar;' and 'var aVar = null;' then ?)
--
Bart
ne...@chthonic.f9.co.uk
Bart Van der Donck wrote:
>
> > That is questionable, since aVar is initialized to `undefined', the sole
> > value of the Undefined type, which is another of the built-in ECMAScript
> > object types, by that statement (see ECMAScript Language Specification,
> > Edition 3 Final, 12.2 Variable statement).
>
> That would be possible, yes. Traditionally, the declaration only
> reserves the name without assigning any value to it.
>
encountered"...
> Maybe javascript has another logic here (what would be the difference
> between executing 'var aVar;' and 'var aVar = null;' then ?)
No maybe about it, ECMAscript behaviour is to do exactly as
Thomas described:
var aVar; results in aVar having the value undefined, regardless of
where
in the particular scope block it appears
var aVar = null; results in aVar having the value undefined until
this line
is executed, whereupon it will have the value null.
Richard Cornford
>> [...]
>>>> You are speculating,
>>>
>>> No, I am not
>>
>> Oh yes you are. You just don't have access to the information
>> necessary to make these generalisations.
>
> Maybe this will convince you. Say the following javascript code:
>
> var aVar;
>
> That was the declaration.
Which causes a property to be created on the Variable object for the
pertinent execution context and its value to be initialised to
Undefined (assuming the property had not previously been created as a
result of an inner function declaration, the function's formal
parameters or a preceding variable declaration using the same
identifier).
> The computer reserves a name 'aVar' for
> future use,
Even if the implementation language is Java and the
'Activation/Variable' object extends HashTable?
> but this name does not refer to a memory address yet at
> this point.
Surly that depend on how the Undefined primitive type is implemented,
among many other things.
> aVar = 5;
>
> That was the assignment. 5 is converted (to keep things
> simple) to binary numerical data ...
There is no need to keep it that simple. Javascript's only numeric type
is a 64 bit IEEE double precision floating point number, so that is how
the number is represented, though almost certainly not directly as the
variable has to know both the type it holds and the value of that type.
<snip>
> ... . Then 00000101 is allocated to an address, let's say we
> name the address ABC. A programmer actually instructs the
> ABC-address to remember the value 00000101 for him, in case
> he would need it later. This memory allocation is a physical
> (electronical/magnetic) thing inside the hardware of your PC.
>
> The variable aVar then gets assigned to memory address ABC.
How could you be certain of that? Surly if a variable holds the address
of a location in memory where the 64 bit IEEE double precision floating
point number is stored the variable will have lost track of the type of
its value, and then how is it supposed to know that it should read 8
bytes from that location instead of, say, one bit to retrieve a boolean
value?
> If we dereference aVar, we don't need name ABC anymore and we
> could free that address (that is, if it was not used by something else
> anymore), and thus gaining memory space to create new addresses.
>
> In old computer languages like Assembler,
And you are describing this as it may be implemented in assembler or C,
while real javascript implementations are more likely to be written in
C++ and be using an object for their 'Variable' object that leverages
the fact that they need a hash-table like object to implement the
native ECMAScript object (so that arbitrary named properties can be
added to, and removed from, the object at run time). With a hash-table
like 'Variable' object it is entirely possible that no additional
memory is allocated at the point of adding a name/value pair to the
object.
I have said it before; you just don't have the information to be making
these types of generalisations about javascript implementations. They
are written in many languages and the specification only requires that
they achieve identical apparent behaviour, implying nothing about the
details of the implementation needed to achieve that behaviour. The
odds are extremely low that even two implementations are similar enough
to justify this type of generalisation.
<snip>
> ... . Thus the term micro-computing and even the company
> MicroSoft (=software for computers with micro-chips).
You realise that most programmes will perceive you as patronising if
you waffle on about the history of computers as if it was unknown.
Richard.
Lasse Reichstein Nielsen
> Maybe this will convince you. Say the following javascript code:
>
> var aVar;
>
> That was the declaration. The computer reserves a name 'aVar' for
> future use, but this name does not refer to a memory address yet at
> this point.
That depends entirely on the implementation.
Most likely the variable is bound to a location containing the
primitive value "undefined", but maybe the declaration just
crates an entry in an internal map structure that has no fixed
location.
I.e., at this point we have:
Symbol table: Maps variable name to location
Store(e.g., memory, or a logical equivalent): Maps locations to values
and the symbol table maps the variable name "aVar" to a location,
let's call it "loc1", and the store maps that location to the
primitive value "undefined" (however that is represented).
The symbol table can contain more information on a variable than its
location. That could be the type of the value stored at the
location. If that is the case, then indeed you don't need to allocate
a location yet, since the initial value of a declared variable is the
undefined value, which is uniquely identified by its type.
> aVar = 5;
>
> That was the assignment. 5 is converted (to keep things simple) to
> binary numerical data (the notation with 1's and 0's).
The string "5" is parsed by the parser and likely converted to the
corresponding value of the Number type (a 64 bit floating point
number).
The left-hand-side is evaluated to the location "loc1" (an
L-value). The value of the right-hand-side is evaluated to the
number value 5.0, and this value is stored in the location "loc1".
That means that executing this assignment statement changes the
*store* to map "loc1" to the value 5.0, and not, as previously, the
value undefined.
> Suppose each memory block consists of 8 bits, then the value would
> become 00000101 in this case.
It wouldn't, unless the Javascript interpreter optimizes integer
values to be stored as non-floating point representations.
More likely is the bit pattern:
0x4014000000000000
But lets let that slide for now.
> Then 00000101 is allocated to an address, let's say we name the
> address ABC.
As an intermediate result, this "address" is likely to be a processor
register, but it can be a stack address too.
Or maybe it is all converted into one machine code instruction that
loads a constant directly into a location, that of the variable,
without an intermediate "landing place".
> A programmer actually instructs the ABC-address to remember the
> value 00000101 for him, in case he would need it later. This memory
> allocation is a physical (electronical/magnetic) thing inside the
> hardware of your PC.
Anything a computer remembers is stored somewhere, whether in main RAM
or in register RAM on the processor.
> The variable aVar then gets assigned to memory address ABC.
That's quite likely not how it happens. The binding from variable to
location in the symbol table is created when the variable is declared
and stays fixed for the lifetime of the variable (ok, maybe the
location changes due to garbage collection if it's not stored on the
stack, but it's not something the programmer controls).
Instead the value at address (or register) ABC is read and then stored
in the location of the variable, i.e., at "loc1" (i.e., the store is
updated to map "loc1" to 5.0 instead of undefined).
> If we dereference aVar, we don't need name ABC anymore and we could
> free that address (that is, if it was not used by something else
> anymore), and thus gaining memory space to create new addresses.
You seem to be looking at the memory at a very low level here, so I
wonder what you mean by "create new addresses". I'm guessing allocation.
> Since a few decades, the jobs of the flikkering lamps were taken over
> by minimal chipsets in stead of bulbs, today they're even 0,001
> millimeter chips or so in stead of 1 meter of bulbs. Thus the term
> micro-computing and even the company MicroSoft (=software for computers
> with micro-chips).
Quite a few years ago, higher level languages were created exactly to
free programmers from having to think at the physical level. A modern
language, like ECMAScript, is not defined in terms of physical actions
at all, merely in terms of its logical semantics. That means that
implementations are free to pick from a wide range of implementation
methods, as long as the final result is consistent with the semantics.
And they do.
Your low-level thinking might be correct for an implementation like
Seamonkey, which is written in a relatively low-level language, C,
but it doesn't match an implementation like "Rhino" that is written
entirely in a very non-physical language, Java.
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Lasse Reichstein Nielsen
> Thomas 'PointedEars' Lahn wrote:
>> That is questionable, since aVar is initialized to `undefined', the sole
>> value of the Undefined type, which is another of the built-in ECMAScript
>> object types, by that statement (see ECMAScript Language Specification,
>> Edition 3 Final, 12.2 Variable statement).
>
> That would be possible, yes. Traditionally, the declaration only
> reserves the name without assigning any value to it.
Which tradition is that? Tradition among Javascript implementations or
among programming languages in general. That latter would be
incorrect. A variable declaration would typically generate an entry
in the symbol table and allocate a location to contain the variable's
value (often by decrementing the stack pointer).
> Maybe javascript has another logic here (what would be the difference
> between executing 'var aVar;' and 'var aVar = null;' then ?)
The difference is that the former makes aVar contain the value
"undefined" whereas the second updates it to contain the value "null".
Both are primitive values, internally each of their own single-valued
type.
Lasse Reichstein Nielsen
> `null' is a primitive value, the sole value of the Null type, which
> is an object type.
It's an "object type" only in the sense that the "typeof" operator
is defined to return the string "object" on either an actual object
or the null value. Internally (as specified by the ECMAScript standard),
it's otherwise no different from the other single-valued type, undefined.
Bart Van der Donck
>[...]
> Browsers are not the only software that executes javascript code, and
> you don't know how it is done in 'a browser', or anywhere else, in
> general. You can only examine how it is done in specific
> implementations, and cannot validly generalise beyond that. When you
> are thinking about this remember that there is at least one javascript
> implementation written in javascript.
It doesn't matter where, when, how, at what time, by whatever
intermediary applications, by what compiler, by who, by what language,
on which computer, etc. the compilation was done. The result on _any_
computer is _always_ the storage of the data as a combination of 0's
and 1's into memory addresses. That _can_ be generalized.
> >> Javascript has no 'pointer' data types
> >
> > Indeed, not at the high javascript code level - but it does at the
> > browser's low compile level.
>
> Not necessarily. IceBrowser uses Rhino for its javascript engine, and
> Rhino is written in Java, so has no pointers. If you insist on going
> down through the layers you will end up at the machine code level,
> where there are no 'pointers',
This is totally wrong. At its basic level, _any_ computer works with
pointers, binary numeric data and memory addresses.
> only integers loaded into data and address registers, etc.
What's that, "integers loaded into data" ? Binary numericals are not
integers, if that's what you mean ? And "loaded into data", does that
mean "allocated to memory addresses" ?
Then your statement could be read as "Binary numerical values that are
allocated to memory addresses". This is indeed the correct description
of what happens then.
> A memory address, it is only conceptually a block when some (byte)
> length information is also associated with the value.
Wrong. A memory address is a physical storage method on a microchip.
> Rhino does not compile javascript to something the machine understands,
> it compiles it to something the JVM understands, and the JVM does the
> next step.
And what is that next step then ? -> Something the machine understands!
:-))
The intermediate steps (eg JVM) are not important, in the end
javascript will always be compiled to machine code. You can't execute
javascript without a computer, right ? In analogy, you can't use memory
if you have no physical place to store it.
> > That's why it's so difficult to
> > influence memory handling from within javascript.
>
> The difficulty is because javascript uses automatic garbage collection,
> which is not intended to be influenced by executing code.
Correct.
> >> its Null value is a primitive
> >
> > No, 'null' is a well defined address (must be)
>
> No, in javascript Null (the value that is assigned with - x = null -)
> is a primitive value, and may or may not have any association with a
> memory address.
That might be the javascript way of presenting 'null'. But, after
compilation, 'null' certainly refers to an existing memory address. How
else could a machine know what 'null' is ?
> > and its reference is
> > somewhere between 0x000 and 0x0000000000000
>
> An address between zero and zero (not a very wide gap)?
It's just a numeric reference. It has no further importance here.
> > (BTW, null is not a value,
> > it's the "not-value" that is defined that way by 0x0...).
>
> Not in javascript. In javascript Null is a primitive type with a single
> value. The nature of that value is not specified or important. It may
> be entirely arbitrary, or borrowed from the implementation language.
I see. It might be the javascript presentation of 'null'.
> Memory allocation is not part of machine code. The lowest level at
> which memory allocation would be expected is at the level of the OS.
Wrong. Memory allocation always happens, independent of any OS. An OS
instructs the memory allocation, yes. But it's the machine that keeps
the data available for future reference. No OS or application can keep
data for you.
C'mon Richard, you're a smart guy. We're just talking about different
levels here, that's all. I don't want to sound patronising to anyone -
I'm just talking about the very electronical, mechanical, magnetical
basics of a computer. Whatever the app or OS, you can't fool Mother
Nature. You can't switch a light on or off if you don't have a light.
I'ld say you are thinking "from the top level" (looking down from
javascript to memory) and I am thinking from the other direction.
--
Bart
VK
Bart Van der Donck wrote:
> > Javascript has no 'pointer' data types
>
> Indeed, not at the high javascript code level - but it does at the
> browser's low compile level.
Not even there - at least not for IE under Windows. Where JScript is a
separate process run by browser from separate system DLL
(%windows%jscript.dll). This DLL in turns uses imported VBScript
modules for low level memory allocation which is turn uses umported
stubs from system.dll which in turn uses core C++ code to say fill RAM
bytes XXXXX123 - XXXXX128 with something useful (and returns it back
later). On this level you are right - but on such low level you could
say as well that JScript operates with binary data only.
> These are just general basic computer
> mechanisms. Every variable points (or 'references' if you like) to a
> memory block address.
That is true for languages with direct memory access (with pointers)
like C or C++. You made a very good attempt to describe JavaScript from
the point of view of C++ but it's futile for that exact reason. Instead
you should look at JavaScript from the Java projection because in
memory management Java is its closest relative.
The only valuable description of JScript memory management I've found
so far (and I was rather insistent) is here:
<http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx>
Further comments on it can be found here:
<http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=fd744276-341d-4d34-87f6-3fb29c09fd8c>
(you may need Microsoft Password to get it, if you have Hotmail account
it will work too).
I cannot comment on any other UA's and other platforms rather than
Windows. No valuable info is found, which doesn't mean of course that
it doesn't exist). With Firefox you for sure can try to find the
relevant block in the distribution source.
Bart Van der Donck
> [...]. Where JScript is a
> separate process run by browser from separate system DLL
> (%windows%jscript.dll). This DLL in turns uses imported VBScript
> modules for low level memory allocation which is turn uses umported
> stubs from system.dll which in turn uses core C++ code to say fill RAM
> bytes XXXXX123 - XXXXX128 with something useful (and returns it back
> later). On this level you are right - but on such low level you could
> say as well that JScript operates with binary data only.
Exactly. I am talking about the most basic level where the OS writes
and reads its stored data (below any application or computer language
or OS-specific functionalitites).
> > These are just general basic computer
> > mechanisms. Every variable points (or 'references' if you like) to a
> > memory block address.
>
> That is true for languages with direct memory access (with pointers)
> like C or C++. You made a very good attempt to describe JavaScript from
> the point of view of C++ but it's futile for that exact reason. Instead
> you should look at JavaScript from the Java projection because in
> memory management Java is its closest relative.
I am not talking about computer languages, but about physical memory
allocation.
> I cannot comment on any other UA's and other platforms rather than
> Windows. No valuable info is found, which doesn't mean of course that
> it doesn't exist). With Firefox you for sure can try to find the
> relevant block in the distribution source.
It doesn't matter if you're using Windows or some UNIX from 1970. It
works the same.
--
Bart
Lasse Reichstein Nielsen
> It doesn't matter where, when, how, at what time, by whatever
> intermediary applications, by what compiler, by who, by what language,
> on which computer, etc. the compilation was done. The result on _any_
> computer is _always_ the storage of the data as a combination of 0's
> and 1's into memory addresses. That _can_ be generalized.
It's also so general that it tells us nothing.
To go back to what I remember as the beginning of this detour: The
representation of the "null" value in Javascript is not in any way
guaranteed to be any specific bit pattern.
> That might be the javascript way of presenting 'null'. But, after
> compilation, 'null' certainly refers to an existing memory address. How
> else could a machine know what 'null' is ?
The null value will probably have a fixed binary representation,
potentially spread over a number of adresses.
There can be more than one null value stored at different locations
in memory.
The interpreter running the Javascript program (or the bytecode
created from the Javascript program) will recognize the bit pattern
wherever it's stored.
No addresses are relevant to this that are not also relevant to
numbers.
> I see. It might be the javascript presentation of 'null'.
It's the Javascript definition of the null type, and null values.
> C'mon Richard, you're a smart guy. We're just talking about different
> levels here, that's all.
Absolutely. But you are making claims about Javascript at a level
where Javascript is not defined. Implementations can agree at the
higher abstraction level and disagree violently at lower levels,
which means that any claim made at a physical level is incorrect
for somec Javascript implementation.
> I don't want to sound patronising to anyone -
> I'm just talking about the very electronical, mechanical, magnetical
> basics of a computer.
We all know about that. What we are failing to see is how it is
relevant.
VK
Bart Van der Donck wrote:
> and reads its stored data (below any application or computer language
> or OS-specific functionalitites).
On such level (which does exists of course) you cannot use then the
terms "variable", "null value", "undefined value" and even "have value
of" itself - these are human abstractions you left on the floor above
(language engine).
Different resolution level - different way to describe the mechanics.
Say electron has a mass (kind of), but you will not use mv^2 on it?
Or say "declare variable before the first use" is a good programming
practice for code reliability and readability. Yet if you dig good
enough in the lower level, you'll find that the parser does
automatically (pre-)declare all var'ed identifiers in your program.
Does it mean that "declare variable before the first use" requirement
is not applicable to JavaScript? Of course not - these are different
unrelated matters (human level and machine level).
Fiiiuuuh... a stone to someone's garden... Just you wait Mr. Higgins...
(never mind, a side comment not to you)
> It doesn't matter if you're using Windows or some UNIX from 1970. It
> works the same.
It doesn't work this way for Sinclair Spectrum from 1982 for sure :-))
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> `null' is a primitive value, the sole value of the Null type, which
>> is an object type.
>
> It's an "object type" only in the sense that the "typeof" operator
> is defined to return the string "object" on either an actual object
> or the null value. Internally (as specified by the ECMAScript standard),
> it's otherwise no different from the other single-valued type, undefined.
`undefined' is the sole value of the _Undefined_ type.
Bart Van der Donck
> Bart Van der Donck wrote:
> > I am talking about the most basic level where the OS writes
> > and reads its stored data (below any application or computer language
> > or OS-specific functionalitites).
>
> On such level (which does exists of course) you cannot use then the
> terms "variable", "null value", "undefined value" and even "have value
> of" itself - these are human abstractions you left on the floor above
> (language engine).
On that level you can only talk about X bits that are 0 or 1 (lamp off
or on) inside each byte. Some might call this undefined/defined,
false/true, no/yes, null/not-null, 0/1, black/white etc. Use what you
like; it's just the boolean principle.
> Different resolution level - different way to describe the mechanics.
> Say electron has a mass (kind of), but you will not use mv^2 on it?
> Or say "declare variable before the first use" is a good programming
> practice for code reliability and readability. Yet if you dig good
> enough in the lower level, you'll find that the parser does
> automatically (pre-)declare all var'ed identifiers in your program.
Javascript declaration and initialization can be joined into one code
instruction (var abc=123 or a=123). No need to do this separately in
javascript.
> Does it mean that "declare variable before the first use" requirement
> is not applicable to JavaScript? Of course not - these are different
> unrelated matters (human level and machine level).
These thoughts are coming from a few levels too high. I don't think
they have anything to do with memory allocation on machine level. The
javascript code will be compiled correctly anyhow.
> > It doesn't matter if you're using Windows or some UNIX from 1970. It
> > works the same.
>
> It doesn't work this way for Sinclair Spectrum from 1982 for sure :-))
It does.
--
Bart
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> >> Javascript has no 'pointer' data types
>> > Indeed, not at the high javascript code level - but it does at the
>> > browser's low compile level.
>> Not necessarily. IceBrowser uses Rhino for its javascript engine, and
>> Rhino is written in Java, so has no pointers. If you insist on going
>> down through the layers you will end up at the machine code level,
>> where there are no 'pointers',
>
> This is totally wrong.
You are quick with unfounded generalizations, and completely discard the
possibility that you do not know everything, or even that you may be wrong.
It's no fun discussing with you.
> At its basic level, _any_ computer works with pointers, binary numeric
> data and memory addresses.
(At a computer's basic level there are electrons or other smallest carriers
of information.) At the lowest machine code level (that is _not_ an
Assembler language!) there are no pointers; there are registers that can
hold _integer_ data (currently mostly stored as binary digits). But it
is still a matter of how you define "machine code level", because Java
bytecode is interpreted by the Java Virtual _Machine_. (/You/ started
this exercise in tetrapilotomy[1], you know.)
PointedEars
___________
[1] The art of splitting a single hair into four parts
(preferably of equal size).
--
Alcohol and Math don't mix. So please don't drink and derive!
Richard Cornford
>>[...]
>> Browsers are not the only software that executes javascript
>> code, and you don't know how it is done in 'a browser', or
>> anywhere else, in general. You can only examine how it is
>> done in specific implementations, and cannot validly
>> generalise beyond that. When you are thinking about this
>> remember that there is at least one javascript
>> implementation written in javascript.
>
> It doesn't matter where, when, how, at what time, by whatever
> intermediary applications, by what compiler, by who, by what
> language, on which computer, etc. the compilation was done.
> The result on _any_ computer is _always_ the storage of the
> data as a combination of 0's and 1's into memory addresses.
> That _can_ be generalized.
And the result is so general that it is utterly trivial. Hardly worth
saying at all.
Remember that you responded to the suggestion that:-
| Setting a pointer to null obviously won't delete the object
| pointed to from memory, but just change the address the
| pointer is referencing (from address of the object to
| null = 0x0000000).
- was pure speculation with the rather specific assertion that "That is
no speculation - it's just how this works", and went on to detail the
precise process of assigning a value to a variable in javascript. These
were not generalisations about how computers work. Rather they were
generalisations about what javascript implementations do, and you don't
have the information necessary to be saying that these things are true
or (or even relevant to) all javascript implementations.
>>>> Javascript has no 'pointer' data types
>>>
>>> Indeed, not at the high javascript code level - but it
>>> does at the browser's low compile level.
>>
>> Not necessarily. IceBrowser uses Rhino for its javascript engine,
>> and Rhino is written in Java, so has no pointers. If you insist
>> on going down through the layers you will end up at the machine
>> code level, where there are no 'pointers',
>
> This is totally wrong. At its basic level, _any_ computer works
> with pointers, binary numeric data and memory addresses.
In machine code there are no pointers. 'Pointer' is a concept that may
apply to some values but that concept is in the mind of the programmer
not inherent in the machine code.
>> only integers loaded into data and address registers, etc.
>
> What's that, "integers loaded into data" ?
Data registers, as in data registers and address reregisters, etc.
(where etc. may be, for example, the program counter).
> Binary numericals are not integers,
Above you described them as "a combination of 0's and 1's", when there
are no actual ones or zeros in the hardware. Any bit pattern can be
conceived as a representation of an integer value.
> if that's what you mean ? And "loaded into data",
> does that mean "allocated to memory addresses" ?
I mean that if you look down as far as the state of the electronic
circuits there is no inherent meaning in anything you see. No pointers,
no allocated memory, not variable and so on.
> Then your statement could be read as "Binary numerical values
> that are allocated to memory addresses". This is indeed the
> correct description of what happens then.
That is writing more in than I meant to say, which was only that at that
lowest level you have nothing but bit patterns in electronic circuits.
that is what happens, but there is little point stating it.
>> A memory address, it is only conceptually a block when
>> some (byte) length information is also associated with
>> the value.
>
> Wrong. A memory address is a physical storage method on a
> microchip.
No they are not, and that was not my point anyway. Conceptually a
'block' has a magnitude in addition to a location. The address is only a
location.
>> Rhino does not compile javascript to something the machine
>> understands, it compiles it to something the JVM understands,
>> and the JVM does the next step.
>
> And what is that next step then ? -> Something the machine
> understands! :-))
> The intermediate steps (eg JVM) are not important,
You said:-
| Referencing and memory allocation take place when
| the browser compiles the javascript to something
| the machine understands.
- in which "the *browser* compiles the javascript to something the
machine understands" (stress added by me) is a questionable assertion
when the browser is written in Java and the javascript complied into
bytecode. It is, as you say, the JVM that produces the actual executable
code, not the browser as you asserted.
And preceding that with "memory allocation take place when ..." is also
questionable as memory allocation may not happen at that point, or not
entirely happen at that point, some of it may be happening later, when
the JVM creates the executable code, or when that code is actually
executed. The language that the browser and javascript interpreter are
written in can make a great deal of difference to where and when memory
allocation may happen. You just don't have the information to generalise
about what a browser may do internally, or when it may do it.
> in the end javascript will always be compiled to
> machine code.
That is not necessarily true. The most that can be said is that
executing javascript involves executing machine code, but that is also
too trivial to be worth saying.
> You can't execute
> javascript without a computer, right ?
That is precisely why the above is trivial.
> In analogy, you can't use
> memory if you have no physical place to store it.
err?
<snip>
>>>> its Null value is a primitive
>>>
>>> No, 'null' is a well defined address (must be)
>>
>> No, in javascript Null (the value that is assigned with
>> - x = null -) is a primitive value, and may or may not
>> have any association with a memory address.
>
> That might be the javascript way of presenting 'null'.
If you are assigning null in javascript it is what null is in javascript
(and what it is not) that is significant.
> But, after compilation, 'null' certainly refers to an
> existing memory address.
Null does not have to be implemented as the sort of thing that refers at
all.
> How else could a machine know what 'null' is ?
The machine doesn't have to care, only the implementation software needs
to have an attitude about how null is implemented.
>> > and its reference is
>> > somewhere between 0x000 and 0x0000000000000
>>
>> An address between zero and zero (not a very wide gap)?
>
> It's just a numeric reference. It has no further
> importance here.
>
>>> (BTW, null is not a value, it's the "not-value"
>>> that is defined that way by 0x0...).
>>
>> Not in javascript. In javascript Null is a primitive type
>> with a single value. The nature of that value is not
>> specified or important. It may be entirely arbitrary, or
>> borrowed from the implementation language.
>
> I see. It might be the javascript presentation of 'null'.
Your mistake here is assuming that null must necessarily have s specific
concrete manifestation. Javascript only requires that null be an
implemented concept, and so it can have any manifestation that the
implementers likes.
>> Memory allocation is not part of machine code. The lowest
>> level at which memory allocation would be expected is at
>> the level of the OS.
>
> Wrong. Memory allocation always happens, independent of
> any OS.
Machine code is capable of addressing any location made available in the
hardware, at any time. The concept of reserving, allocating and freeing
areas in memory needs to be implemented by a programmer, it is not
inherent in machine code.
> An OS instructs the memory allocation, yes. But it's the
> machine that keeps the data available for future reference.
But the hardware does not prevent any machine code from writing to any
memory at any time. That level of control of memory access is something
that is programmed as a layer above the hardware, and usually that
program is a fundamental aspect of the OS.
> No OS or application can keep
> data for you.
The OS can, and usually does, impose the control over which software
uses which memory, when and how.
> C'mon Richard, you're a smart guy. We're just talking
> about different levels here, that's all.
We are supposed to e talking about javascript here, so your
generalisations about the behaviour of javascript interprets and web
browsers pitched at a level below the javascript implementation, are
inappropriate, irrelevant, and probably wrong due to the freedom
allotted to the implementers to achieve the required behaviour in any
way the want.
<snip>
> I'ld say you are thinking "from the top level" (looking
> down from javascript to memory) and I am thinking from the
> other direction.
Looking down it is possible to see that the possible permutations
multiply so rapidly at the implementation level that it cannot be
possible to declare a single outcome at the lowest level without that
outcome being so trivial that it has no relevance to the actual writing
of javascript code. That also makes it obvious that starting at the
lowest level with any specific scheme cannot lead back up to any
generalisations about javascript.
The bottom line is that it doesn't matter what null may actually be,
just that assigning null to a variable that previously was the only
reference to an object will result in there being no accessible
references to the object remaining in the system. So that object then
becomes available for automated garbage collection, which may happen at
any subsequent point but should result in resources consumed by the
object becoming available again (in some sense).
Richard.
Lasse Reichstein Nielsen
> Lasse Reichstein Nielsen wrote:
[about "null"]
>> Internally (as specified by the ECMAScript standard),
>> it's otherwise no different from the other single-valued type, undefined.
>
> `undefined' is the sole value of the _Undefined_ type.
... just as "null" is the sole value of the _Null_ type.
One could argue that the Null type isn't really necessary.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> Lasse Reichstein Nielsen wrote:
> [about "null"]
>>> Internally (as specified by the ECMAScript standard),
>>> it's otherwise no different from the other single-valued type,
>>> undefined.
>>
>> `undefined' is the sole value of the _Undefined_ type.
>
> ... just as "null" is the sole value of the _Null_ type.
ACK. There is in fact no notion in the specification that Null or
Undefined are Object types. And especially the definition of the
internal ToPrimitive operator suggests that they are not. I got
confused with all Object types starting with capital letters, and
assumed that therefore (and because of `typeof null') Null and
Undefined are Object types, too. My bad.
> One could argue that the Null type isn't really necessary.
ACK. But from what I can see, the specification of operators
and algorithms would have been more complicated without it.
PointedEars
--
A man who works with his hands is a laborer; a man who works with his
hands and his brain is a craftsman; but a man who works with his hands
and his brain and his heart is an artist.
-- Louis Nizer, lawyer (1902-1994)
VK
> > One could argue that the Null type isn't really necessary.
Thomas 'PointedEars' Lahn wrote:
> ACK. But from what I can see, the specification of operators
> and algorithms would have been more complicated without it.
"null" and "undefined" (and the 3rd "empty" in some languages but not
in JavaScript) are abstactions over the concept of "nothing is here".
It is like an empty room where I took every single item out, and
another empty room no one ever put any item in yet.
Factually it is the same empty room in either case. But in the first
case the emptiness is the result of an explicit action, in the second
case it is the default "natural" state. The first case is "null", the
second case is "undefined". This distinction is being useful in some
cases. JavaScript though has a specific of having "undefined" as a
value one can /assign/ as any other value. IMHO that is one of cases
then in attempt to simplify one matter they unnecessary complicate
other. IMHO.
Richard Cornford
<snip>
> "null" and "undefined" (and the 3rd "empty" in some languages but
> not in JavaScript) are abstactions over the concept of "nothing is
> here". It is like an empty room where I took every single item out,
> and another empty room no one ever put any item in yet.
> Factually it is the same empty room in either case.
You really are not up to much when it comes to logic, are you? Unless
taking every single item out of a room involves taking nothing at all
out, an empty room that you took everything out of cannot be "the same
empty room" as an empty room no one ever put anything into. Because the
second room never contained anything that could be taken out and so
could not be a room from which anything was taken.
<snip>
> ... . IMHO that is one of cases then in attempt to simplify one
> matter they unnecessary complicate other. IMHO.
Your opinions are worthless and may as well be kept to yourself.
Richard.
VK
> > ... . IMHO that is one of cases then in attempt to simplify one
> > matter they unnecessary complicate other. IMHO.
Richard Cornford wrote:
> Your opinions are worthless and may as well be kept to yourself.
IYMHO (In Your Most Humble Opinion).
Richard Cornford
> Richard Cornford wrote:
>> VK wrote:
>>> ... . IMHO that is one of cases then in attempt to simplify one
>>> matter they unnecessary complicate other. IMHO.
>
>
> IYMHO (In Your Most Humble Opinion).
My opinion maybe, but a long way from being only my opinion.
Richard.
Randy Webb
I think it would be safe to add "and at least 100 other peoples opinion"
if not more than 100.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Bart Van der Donck
> [...]
> "null" and "undefined" (and the 3rd "empty" in some languages but not
> in JavaScript) are abstactions over the concept of "nothing is here".
> It is like an empty room where I took every single item out, and
> another empty room no one ever put any item in yet.
> Factually it is the same empty room in either case. But in the first
> case the emptiness is the result of an explicit action, in the second
> case it is the default "natural" state. The first case is "null", the
> second case is "undefined". This distinction is being useful in some
> cases. JavaScript though has a specific of having "undefined" as a
> value one can /assign/ as any other value. IMHO that is one of cases
> then in attempt to simplify one matter they unnecessary complicate
> other. IMHO.
Null is non-defined and is not empty (which would be a defined value,
namely the empty value).
In your analogy, an empty room is like this:
var room = '';
A room "of which nothing can be said", is like this:
var room = null;
--
Bart
Matt Kruse
> "null" and "undefined" (and the 3rd "empty" in some languages but not
> in JavaScript) are abstactions over the concept of "nothing is here".
So both could be used to describe your working knowledge of js? ;)
Imagine 2 signs, "A" and "B", and third sign "C" which someone told you they
were going to make soon.
The "A" sign is placed on a box, and the "B" sign isn't placed on anything.
"A" points to an object.
"B" points to nothing at the moment (null)
If someone asks what "C" points to, you would have to ask "What C? There is
no C yet."
"C" is undefined.
Your assertion that "B" and "C" both have the same meaning is incorrect.
--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Bart Van der Donck
> "Bart Van der Donck" <ba...@nijlen.com> writes:
>
> > Maybe this will convince you. Say the following javascript code:
> >
> > var aVar;
> >
> > That was the declaration. The computer reserves a name 'aVar' for
> > future use, but this name does not refer to a memory address yet at
> > this point.
>
> That depends entirely on the implementation.
I am not talking about any implementation. I am talking about the
lowest level that works the same on a PC, a mobile phone, a calculator,
a coffee machine that starts automatically at 7:00AM, and on VK's Atari
of 1982.
> Most likely the variable is bound to a location containing the
> primitive value "undefined", but maybe the declaration just
> crates an entry in an internal map structure that has no fixed
> location.
>
> I.e., at this point we have:
>
> Symbol table: Maps variable name to location
> Store(e.g., memory, or a logical equivalent): Maps locations to values
>
> and the symbol table maps the variable name "aVar" to a location,
> let's call it "loc1", and the store maps that location to the
> primitive value "undefined" (however that is represented).
Your "loc1" is what I described as "ABC" in my example.
The 'undefined' value might be stored pointing to 'loc1' at that
moment. I don't know that. The storage of 'loc1' (the location) and
'undefined' (its value) are 2 separate actions of the processor though.
The declaration is only the first action. The second action is the
assignment, which stores something for 'loc1' (in this case
'undefined'). It's like saying: (1) I answer this usenet post (2) with
'blablabla'. No that is not to be read as a Freudian example :-)
(2) cannot be said before (1), or without (1). (1) can be said without
continueing to (2) though.
> The symbol table can contain more information on a variable than its
> location. That could be the type of the value stored at the
> location. If that is the case, then indeed you don't need to allocate
> a location yet, since the initial value of a declared variable is the
> undefined value, which is uniquely identified by its type.
This might happen somewhere, but not at ground floor. 'loc1' is a
series of bits and 'undefined' is another series of bits. It' just
coinicidental that they become a name/value pair.
> > aVar = 5;
> >
> > That was the assignment. 5 is converted (to keep things simple) to
> > binary numerical data (the notation with 1's and 0's).
>
> The string "5" is parsed by the parser and likely converted to the
> corresponding value of the Number type (a 64 bit floating point
> number).
>
> The left-hand-side is evaluated to the location "loc1" (an
> L-value). The value of the right-hand-side is evaluated to the
> number value 5.0, and this value is stored in the location "loc1".
>
> That means that executing this assignment statement changes the
> *store* to map "loc1" to the value 5.0, and not, as previously, the
> value undefined.
Supposed that the location of that 'undefined' took place in the
beginning, I think this represenation is correct.
> > Suppose each memory block consists of 8 bits, then the value would
> > become 00000101 in this case.
>
> It wouldn't, unless the Javascript interpreter optimizes integer
> values to be stored as non-floating point representations.
> More likely is the bit pattern:
> 0x4014000000000000
> But lets let that slide for now.
In my view, you're on floor 1 here :-)
Suppose we have some bytes on a 3bit computer. If we're on floor 1
(bytes), then the digit 5 would be stored as 101 (3 bits) on floor 0.
An old computer would allocate '5' as one bulb on, the second off, the
third on (101). If that value 5 would change to e.g. value 0 at some
moment, the three bulbs would go off (000). This is just binary numeric
data
http://en.wikipedia.org/wiki/Binary_numeral_system
> > Then 00000101 is allocated to an address, let's say we name the
> > address ABC.
>
> As an intermediate result, this "address" is likely to be a processor
> register, but it can be a stack address too.
>
> Or maybe it is all converted into one machine code instruction that
> loads a constant directly into a location, that of the variable,
> without an intermediate "landing place".
I'm afraid I lost you here.
> > A programmer actually instructs the ABC-address to remember the
> > value 00000101 for him, in case he would need it later. This memory
> > allocation is a physical (electronical/magnetic) thing inside the
> > hardware of your PC.
>
> Anything a computer remembers is stored somewhere, whether in main RAM
> or in register RAM on the processor.
Or whatever medium that can store the bits per byte. Chipsets, tape,
data cards, or actually any binary representation (you don't even need
electricity for this, at least in theory). The lamp on my desk stores 1
bit too, because it's on or off. I'ld say a lamp is a 1-byte-1-bit
computer at its simplest form :-)
> > If we dereference aVar, we don't need name ABC anymore and we could
> > free that address (that is, if it was not used by something else
> > anymore), and thus gaining memory space to create new addresses.
>
> You seem to be looking at the memory at a very low level here, so I
> wonder what you mean by "create new addresses". I'm guessing allocation.
Yes, I meant (existing) addresses that were not in use.
> > Since a few decades, the jobs of the flikkering lamps were taken over
> > by minimal chipsets in stead of bulbs, today they're even 0,001
> > millimeter chips or so in stead of 1 meter of bulbs. Thus the term
> > micro-computing and even the company MicroSoft (=software for computers
> > with micro-chips).
>
> Quite a few years ago, higher level languages were created exactly to
> free programmers from having to think at the physical level. A modern
> language, like ECMAScript, is not defined in terms of physical actions
> at all, merely in terms of its logical semantics. That means that
> implementations are free to pick from a wide range of implementation
> methods, as long as the final result is consistent with the semantics.
> And they do.
>
> Your low-level thinking might be correct for an implementation like
> Seamonkey, which is written in a relatively low-level language, C,
> but it doesn't match an implementation like "Rhino" that is written
> entirely in a very non-physical language, Java.
Well - it's the basic computing mechanism, below any implementation
level. Say you have 13 transparent cards divided into 2 series, one
series with values 10,20,30 on it and one series with values
0,1,2,3,4,5,6,7,8,9. The first cards have blanco spaces on the 0. If
you put a card from the second series above one of the first series,
you see the addition of the both integers they represent. That is a
computer where each card represents a byte.
--
Bart
Bart Van der Donck
> "Bart Van der Donck" <ba...@nijlen.com> writes:
> > [...] Traditionally, the declaration only
> > reserves the name without assigning any value to it.
>
> Which tradition is that? Tradition among Javascript implementations or
> among programming languages in general. That latter would be
> incorrect. A variable declaration would typically generate an entry
> in the symbol table and allocate a location to contain the variable's
> value (often by decrementing the stack pointer).
Aren't we saying the same here ?
BVDD: "the declaration only reserves the name without assigning any
value to it"
LRN: "a variable declaration would typically generate an entry in the
symbol table and allocate a location to contain the variable's value"
In reply to your question:
The tradition is that declaration and assignment are different things.
The lower the language level, the clearer this is in the code syntax.
> > Maybe javascript has another logic here (what would be the difference
> > between executing 'var aVar;' and 'var aVar = null;' then ?)
>
> The difference is that the former makes aVar contain the value
> "undefined" whereas the second updates it to contain the value "null".
> Both are primitive values, internally each of their own single-valued
> type.
I accept that javascript implements it this way.
--
Bart
Lasse Reichstein Nielsen
> Lasse Reichstein Nielsen wrote:
>
> Your "loc1" is what I described as "ABC" in my example.
>
> The 'undefined' value might be stored pointing to 'loc1' at that
> moment.
That's where I don't follow. Values do not point to anything.
> I don't know that. The storage of 'loc1' (the location) and
> 'undefined' (its value) are 2 separate actions of the processor though.
Correct. Storing the binding of the variable name to the location and
storing the values in the location are two seperate actions. In a
traditional compiled language, the former would be performed at
compile time, and the latter at runtime.
Bart Van der Donck
> [...]
> > The 'undefined' value might be stored pointing to 'loc1' at that
> > moment.
>
> That's where I don't follow. Values do not point to anything.
Yes - actually it's the other way around. 'loc1' (name) points to
'undefined' (its stored value).
--
Bart
Bart Van der Donck
> Remember that you responded to the suggestion that:-
>
> | Setting a pointer to null obviously won't delete the object
> | pointed to from memory, but just change the address the
> | pointer is referencing (from address of the object to
> | null = 0x0000000).
>
> - was pure speculation with the rather specific assertion that "That is
> no speculation - it's just how this works", and went on to detail the
> precise process of assigning a value to a variable in javascript. These
> were not generalisations about how computers work. Rather they were
> generalisations about what javascript implementations do, and you don't
> have the information necessary to be saying that these things are true
> or (or even relevant to) all javascript implementations.
I'ld say it's a buffering issue then. When a variable gets a new value,
there are 2 possible ways:
(1) The memory address gets populated with new bytes; or
(2) It points to another memory address, where the original address
keeps its current content (and is not freed).
> In machine code there are no pointers. 'Pointer' is a concept that may
> apply to some values but that concept is in the mind of the programmer
> not inherent in the machine code.
I'm not sure if there's a physical equivalent for a pointer. But no
computer can work without the concept. The bits itself do not mean
anything - together they form a byte, and the byte responds to
something in the mind of the programmer.
> > Binary numericals are not integers,
>
> Above you described them as "a combination of 0's and 1's", when there
> are no actual ones or zeros in the hardware. Any bit pattern can be
> conceived as a representation of an integer value.
Not directly. The traditional representation of a bit pattern since
many decades is a range holding ones and zeros. It's an abstraction of
course. You could think of it as a bunch of people, where males are 0
and females 1, for example.
> > if that's what you mean ? And "loaded into data",
> > does that mean "allocated to memory addresses" ?
>
> I mean that if you look down as far as the state of the electronic
> circuits there is no inherent meaning in anything you see. No pointers,
> no allocated memory, not variable and so on.
Correct, no variables. But allocating memory is certainly happening by
means of electronic circuits (which is how chipsets hold data).
> > Then your statement could be read as "Binary numerical values
> > that are allocated to memory addresses". This is indeed the
> > correct description of what happens then.
>
> That is writing more in than I meant to say, which was only that at that
> lowest level you have nothing but bit patterns in electronic circuits.
Yes, that is correct.
> > Wrong. A memory address is a physical storage method on a
> > microchip.
>
> No they are not, and that was not my point anyway. Conceptually a
> 'block' has a magnitude in addition to a location. The address is only a
> location.
No. Memory is a physically stored range of bit statusses. Say I have 2
bottles (each bottle is a bit, together they represent 1 byte). Then I
imagine that:
- 0 is the equivalent of two empty bottles
- 1 is the equivalent of a full bottle + an empty bottle
- 2 is the equivalent of an empty bottle + a full bottle
- 3 is the equivalent of two full bottles
Suppose I want to remember the value "3" for later, then I fill both
bottles. I can go eat a sandwich and come back. Then I want to recall
which value I had alloacted. I see two full bottles so the value is
three. The bottles have remembered my value, not me. This is how
memory allocation works.
> | Referencing and memory allocation take place when
> | the browser compiles the javascript to something
> | the machine understands.
>
> - in which "the *browser* compiles the javascript to something the
> machine understands" (stress added by me) is a questionable assertion
> when the browser is written in Java and the javascript complied into
> bytecode. It is, as you say, the JVM that produces the actual executable
> code, not the browser as you asserted.
Sure, that's correct. If you have an iron with javascript support, the
iron would compile the javascript code.
> [...]
--
Bart
Bart Van der Donck
> You are quick with unfounded generalizations, and completely discard the
> possibility that you do not know everything, or even that you may be wrong.
> It's no fun discussing with you.
I do not discard that possibility - never have, never will. Feel free
to search my usenet reputation, I'm the first to admit inaccurate
terminology or errors.
> > At its basic level, _any_ computer works with pointers, binary numeric
> > data and memory addresses.
>
> (At a computer's basic level there are electrons or other smallest carriers
> of information.) At the lowest machine code level (that is _not_ an
> Assembler language!) there are no pointers; there are registers that can
> hold _integer_ data (currently mostly stored as binary digits).
I wouldn't say 'mostly', but 'always'. I'm not aware of any system that
doesn't store RAM as binary digits, and I'm not sure if this is
überhaupt possible.
--
Bart
Lasse Reichstein Nielsen
> I'm not aware of any system that doesn't store RAM as binary digits,
> and I'm not sure if this is überhaupt possible.
It's possible, and there were attempts in the early days of computers
to build decimal based computers. It just turned out to be too fragile.
Distinguishing between ten levels of voltage was more errorprone than
just between "on" and "off".
I believe both the Eniac and the Mark I were decimal.
It'll be interesting to see whether optical computers will be able
to be non-binary, and whether there is anything to gain from it.
VK
Bart Van der Donck wrote:
> doesn't store RAM as binary digits, and I'm not sure if this is
> überhaupt possible.
If you decided to go back up to Big Bang both in time and space :-):
the very first big /electronic/ computers for statistical calculations
operated with analog electric potentials - so the result was the
resulting potential affected by input potentials (arguments we would
say now). Kind of the Old Greek "calculator gismo" made of pipes and
jars where you pull water on the top and see the solution by how and
what jars are filled at the bottom.
That is about "überhaupt possible" :-) - but naturally all modern
computers operate with discret signals based /internally/ on binary
on/off system.
But it has no relevance to the memory management in JavaScript/JScript
(nor to any other higher level language for this matter).
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> > At its basic level, _any_ computer works with pointers, binary numeric
>> > data and memory addresses.
>> (At a computer's basic level there are electrons or other smallest
>> carriers of information.) At the lowest machine code level (that is
>> _not_ an Assembler language!) there are no pointers; there are registers
>> that can hold _integer_ data (currently mostly stored as binary digits).
>
> I wouldn't say 'mostly', but 'always'. I'm not aware of any system
> that doesn't store RAM as binary digits, and I'm not sure if this is
> überhaupt possible.
Get informed about quantum computers, for example.
PointedEars
--
In the First World War, 13 million people were killed. In the Second
World War, 40 million people were killed. I think that if a third war
takes place, nothing is going to be left on the face of earth.
-- Shakira, 2003-02-05 @ MTV.com
Richard Cornford
>> Remember that you responded to the suggestion that:-
>>
>>| Setting a pointer to null obviously won't delete the
>>| object pointed to from memory, but just change the
>>| address the pointer is referencing (from address of
>>| the object to null = 0x0000000).
>>
>> - was pure speculation with the rather specific assertion
>> that "That is no speculation - it's just how this works",
>> and went on to detail the precise process of assigning a
>> value to a variable in javascript. These were not
>> generalisations about how computers work. Rather they were
>> generalisations about what javascript implementations do,
>> and you don't have the information necessary to be saying
>> that these things are true or (or even relevant to) all
>> javascript implementations.
>
> I'ld say it's a buffering issue then.
Then I would say that you are being irrelevant.
> When a variable gets a new value,
This would be a javascript variable? Something that is specified as a
property added to a dynamic object and, by implication, has both value
and type. That may make a javascript variable a structure attached in
some way to another structure, where both the structures and the nature
of their attachment are no more than possibilities that may be manifest
in the implementation, may have almost any arbitrary form and will be
influenced by the implementation language.
> there are 2 possible ways:
No there are not. There is a very wide spectrum of possibilities in
implementing javascript variables.
> (1) The memory address gets populated with new bytes; or
"The memory address"? In practice hundreds of memory addresses may have
new values written to them during the creation of a javascript variable.
> (2) It points to another memory address, where the original
> address keeps its current content (and is not freed).
If you are going to think about it on this level there is only one
possibility; The creation of a javascript variable results in values
being written into bytes at memory addresses. There is absolutely no
point in saying so, because that is both obvious and trivial.
>> In machine code there are no pointers. 'Pointer' is a concept
>> that may apply to some values but that concept is in the mind
>> of the programmer not inherent in the machine code.
>
> I'm not sure if there's a physical equivalent for a
> pointer.
A program counter, as a register that is intended to only hold a
reference to a memory location, is probably as close as hardware gets to
having a 'pointer' (and, unlike address registers, you would come
unstuck pretty quickly if you attempted to store data in a program
counter).
> But no computer can work without the concept.
Computers are machines, they work quite successfully without perception
or conception.
While computers must interpret some bit patterns as memory addresses the
bit pattern is only a memory address at the point when it is used as a
memory address. In machine code there are no 'pointers', only the act of
addressing memory.
> The bits itself do not mean anything - together they
> form a byte, and the byte responds to
> something in the mind of the programmer.
I assume that was supposed to be 'the byte _corresponds_ to ...'.
Which makes my point, at the very lowest level there is no meaning, and
at the javascript level the lowest level has been hidden behind a
spectrum of (largely unimportant) implementation details. Picking some
arbitrary level in-between and trying to make generalisations about
javascript is not a viable (or valuable) practice.
>>> Binary numericals are not integers,
>>
>> Above you described them as "a combination of 0's and 1's",
>> when there are no actual ones or zeros in the hardware. Any
>> bit pattern can be conceived as a representation of an integer
>> value.
>
> Not directly. The traditional representation of a bit pattern
> since many decades is a range holding ones and zeros.
Are you saying that ones and zeros are not intergers?
> It's an abstraction of course.
Yes, as is thinking about bit patterns as integers, or hex numbers. I
would say that hex was the most traditional representation of a bit
pattern.
> You could think of it as a bunch of people, where males
> are 0 and females 1, for example.
Why on earth would I want to do that?
>>> if that's what you mean ? And "loaded into data",
>>> does that mean "allocated to memory addresses" ?
>>
>> I mean that if you look down as far as the state of the
>> electronic circuits there is no inherent meaning in anything
>> you see. No pointers, no allocated memory, not variable and
>> so on.
>
> Correct, no variables.
Nor any other meaningful concepts.
> But allocating memory is certainly happening by means
> of electronic circuits (which is how chipsets hold data).
Electronic circuits acting under the direction of a program. The meaning
of what those circuits are doing comes from the programmer. If the
programmer has programmed memory allocation the circuits are not aware
that memory allocation is what they are doing, and you could not validly
deduce that memory allocation was the concept in the mind of the
programmer by observing the actions of the circuits (even if you could
assert a strong probability to making that conclusion form some
observations).
>>> Then your statement could be read as "Binary numerical
>>> values that are allocated to memory addresses". This is
>>> indeed the correct description of what happens then.
>>
>> That is writing more in than I meant to say, which was only
>> that at that lowest level you have nothing but bit patterns
>> in electronic circuits.
>
> Yes, that is correct.
>
>>> Wrong. A memory address is a physical storage method on a
>>> microchip.
>>
>> No they are not, and that was not my point anyway. Conceptually
>> a 'block' has a magnitude in addition to a location. The address
>> is only a location.
>
> No. Memory is a physically stored range of bit statusses.
Memory is not "a memory address", which is what your statement above is
about.
> Say I have 2
> bottles (each bottle is a bit, together they represent 1 byte).
> Then I imagine that:
> - 0 is the equivalent of two empty bottles
> - 1 is the equivalent of a full bottle + an empty bottle
> - 2 is the equivalent of an empty bottle + a full bottle
> - 3 is the equivalent of two full bottles
>
> Suppose I want to remember the value "3" ...
<snip>
I thought you didn't want to be patronising? For future reference; I
know enough about electronics to build a working computer out of valves,
relays or transistors for myself (in the very unlikely event that doing
so become necessary, given the wide availability of microchips in
general).
>>| Referencing and memory allocation take place when
>>| the browser compiles the javascript to something
>>| the machine understands.
>>
>> - in which "the *browser* compiles the javascript to something the
>> machine understands" (stress added by me) is a questionable assertion
>> when the browser is written in Java and the javascript complied into
>> bytecode. It is, as you say, the JVM that produces the actual
>> executable code, not the browser as you asserted.
>
> Sure, that's correct. If you have an iron with javascript
> support, the iron would compile the javascript code.
Which is as worthless as a statement as saying that a computer will
compile the javascript code that is executed on it. You original stamens
related to the behaviour and actions of browsers and the javascript
implementations that they contain.
Richard.
Bart Van der Donck
> Bart Van der Donck wrote:
> > Richard Cornford wrote:
> >> Remember that you responded to the suggestion that:-
> >>
> >>| Setting a pointer to null obviously won't delete the
> >>| object pointed to from memory, but just change the
> >>| address the pointer is referencing (from address of
> >>| the object to null = 0x0000000).
> >>
> >> - was pure speculation with the rather specific assertion
> >> that "That is no speculation - it's just how this works",
> >> and went on to detail the precise process of assigning a
> >> value to a variable in javascript. These were not
> >> generalisations about how computers work. Rather they were
> >> generalisations about what javascript implementations do,
> >> and you don't have the information necessary to be saying
> >> that these things are true or (or even relevant to) all
> >> javascript implementations.
> >
> > I'ld say it's a buffering issue then.
>
> Then I would say that you are being irrelevant.
Yes, that is irrelevant to this group.
> > When a variable gets a new value,
>
> This would be a javascript variable? Something that is specified as a
> property added to a dynamic object and, by implication, has both value
> and type. That may make a javascript variable a structure attached in
> some way to another structure, where both the structures and the nature
> of their attachment are no more than possibilities that may be manifest
> in the implementation, may have almost any arbitrary form and will be
> influenced by the implementation language.
>
> > there are 2 possible ways:
>
> No there are not. There is a very wide spectrum of possibilities in
> implementing javascript variables.
In javascript variables, yes. Not in traditional, computer-scientific
variables. I repeatedly said I am not talking about javascript
authoring.
> > (1) The memory address gets populated with new bytes; or
>
> "The memory address"? In practice hundreds of memory addresses may have
> new values written to them during the creation of a javascript variable.
Yes that is almost certain, considering the generation of languages
javascript belongs to.
> [...]
> Computers are machines, they work quite successfully without perception
> or conception.
That's correct for the machine itself (hardware). Once you leave the
byte-level, everything hangs together with conceptions and perceptions
(software).
> While computers must interpret some bit patterns as memory addresses the
> bit pattern is only a memory address at the point when it is used as a
> memory address. In machine code there are no 'pointers', only the act of
> addressing memory.
Computers do not interpret anything. They only read and write to memory
addresses (allocate/reallocate), where each bit pattern represents 1
byte, whatever that byte may further represent to the programmer.
> > The bits itself do not mean anything - together they
> > form a byte, and the byte responds to
> > something in the mind of the programmer.
>
> I assume that was supposed to be 'the byte _corresponds_ to ...'.
Yes.
> Which makes my point, at the very lowest level there is no meaning, and
> at the javascript level the lowest level has been hidden behind a
> spectrum of (largely unimportant) implementation details. Picking some
> arbitrary level in-between and trying to make generalisations about
> javascript is not a viable (or valuable) practice.
I am not picking out an arbitrary level, I am dealing with the lowest
level. I do not want to claim anything about any javascript
implementation, though I made an example in javascript syntax which
might have confused (where I talked about aVar = 5). I described how
the principle behaves at its lowest level, not how it might be
implemented in javascript (how could I know this ? for which javascript
implemenation would I speak then ? how would I know which other
technologies would be used inside that one specific implementation ?
which intermediary levels are still between that implemenation and the
machine ? etc.)
In my opinion, the core of this discussion is a different level where
you keep repeating how things work in javascript, and I keep repeating
how it works in computer core. What's in between those two, can only be
guessed at, or it's work for a bunch of experts that are only
specialised in their own application fields.
> >> Above you described them as "a combination of 0's and 1's",
> >> when there are no actual ones or zeros in the hardware. Any
> >> bit pattern can be conceived as a representation of an integer
> >> value.
> >
> > Not directly. The traditional representation of a bit pattern
> > since many decades is a range holding ones and zeros.
>
> Are you saying that ones and zeros are not intergers?
Depends how you look at them. If you consider them part of the whole
numbers (positive, negative, or zero), than the answer is yes. In
binary numerals, zeros and ones are digits, *not* integers.
> > It's an abstraction of course.
>
> Yes, as is thinking about bit patterns as integers, or hex numbers. I
> would say that hex was the most traditional representation of a bit
> pattern.
Thinking about bit patterns in non-binary terms is one step away from
their essence. Any representation that follows the "bi-al" concept,
suits. Hexadecimals or integers are next-level representations in the
mind of the programmer.
> > You could think of it as a bunch of people, where males
> > are 0 and females 1, for example.
>
> Why on earth would I want to do that?
Because that representation is (for example) suitable to describe the
working of bits in a byte at its most elementary level. The "bunch of
people" is a byte. Hex or integers (or whatever other non-binary
representations) originate from a higher level.
> [...]
> I thought you didn't want to be patronising? For future reference; I
> know enough about electronics to build a working computer out of valves,
> relays or transistors for myself
Depends what you define as a computer, of course :-) I don't have your
electronic background, but it's quite some claim that you could build
your own computer that way (worthy that name).
> > Sure, that's correct. If you have an iron with javascript
> > support, the iron would compile the javascript code.
>
> Which is as worthless as a statement as saying that a computer will
> compile the javascript code that is executed on it. You original stamens
> related to the behaviour and actions of browsers and the javascript
> implementations that they contain.
You're nitt-picking, but you're right of course. An iron can't compile,
it needs at least an OS for that. I just assumed any device supporting
javascript would have an OS.
--
Bart
Thomas 'PointedEars' Lahn
> Richard Cornford wrote:
>> Bart Van der Donck wrote:
>> > Richard Cornford wrote:
>> >> Remember that you responded to the suggestion that:-
>> >>| Setting a pointer to null obviously won't delete the
>> >>| object pointed to from memory, but just change the
>> >>| address the pointer is referencing (from address of
>> >>| the object to null = 0x0000000).
>> >> - was pure speculation with the rather specific assertion
>> >> that "That is no speculation - it's just how this works",
>> >> and went on to detail the precise process of assigning a
>> >> value to a variable in javascript. These were not
>> >> generalisations about how computers work. Rather they were
>> >> generalisations about what javascript implementations do,
>> >> and you don't have the information necessary to be saying
>> >> that these things are true or (or even relevant to) all
>> >> javascript implementations.
>> > I'ld say it's a buffering issue then.
>> Then I would say that you are being irrelevant.
>
> Yes, that is irrelevant to this group.
If you can agree with that, why do you not just stop posting off topic?
>> > When a variable gets a new value,
>>
>> This would be a javascript variable? Something that is specified as a
>> property added to a dynamic object and, by implication, has both value
>> and type. That may make a javascript variable a structure attached in
>> some way to another structure, where both the structures and the nature
>> of their attachment are no more than possibilities that may be manifest
>> in the implementation, may have almost any arbitrary form and will be
>> influenced by the implementation language.
>>
>> > there are 2 possible ways:
>> No there are not. There is a very wide spectrum of possibilities in
>> implementing javascript variables.
>
> In javascript variables, yes.
You miss the point. Richard is talking about the possibilities of the
_implementation of_ "javascript" variables (in another programming
language). (Which IMHO is *still* on-topic here.)
> Not in traditional, computer-scientific variables.
Yes, there is. As I stated long before in this thread, special values in
a programming language can be implemented (usually in another, lower-level
programming language) using /any/ value or combination of values in that
implementation language that is not used otherwise for the implementation
of the other language. Implementing ECMAScript's primitive `null' value
as a NULL pointer (0x0000) in C, for example, is a possibility, not a
necessity (and it is an impossibility if the implementation is written
e.g. in Java instead of C, as Java has no concept of pointers itself).
You do not look very smart ignoring this very simple fact repeatedly, while
rambling and patronizing knowledgeable people about quite irrelevant
possible implementations of data storage in hardware. Nuff said.
PointedEars
--
Bill Gates isn't the devil -- Satan made sure hell
_worked_ before he opened it to the damned ...
Bart Van der Donck
> [...]
> You do not look very smart ignoring this very simple fact repeatedly, while
> rambling and patronizing knowledgeable people about quite irrelevant
> possible implementations of data storage in hardware. Nuff said.
Play the ball, not the person, Thomas.
As a gentleman I'm offering the final word to you, Richard. If you're a
gentleman too, pls don't abuse this gesture then.
--
Bart
Randy Webb
> Thomas 'PointedEars' Lahn wrote:
>
>> [...]
>> You do not look very smart ignoring this very simple fact repeatedly, while
>> rambling and patronizing knowledgeable people about quite irrelevant
>> possible implementations of data storage in hardware. Nuff said.
>
> Play the ball, not the person, Thomas.
That is the problem, and Thomas has shown it repeatedly. When he can't
play the ball, he turns to the person and he very seldom plays the ball.
I have been plonked and un-plonked by him so many times I call myself
the President of the "Thomas called me a Troll" club.
Matt Kruse
> I have been plonked and un-plonked by him so many times I call myself
> the President of the "Thomas called me a Troll" club.
If you would just read ECMA Specification version 15.43.24.5 section 5,
paragraph 4, you would know why.
Score adjusted
John W. Kennedy
> "Bart Van der Donck" <ba...@nijlen.com> writes:
>
>> I'm not aware of any system that doesn't store RAM as binary digits,
>> and I'm not sure if this is überhaupt possible.
>
> It's possible, and there were attempts in the early days of computers
> to build decimal based computers. It just turned out to be too fragile.
> Distinguishing between ten levels of voltage was more errorprone than
> just between "on" and "off".
>
> I believe both the Eniac and the Mark I were decimal.
The ASSC ("Mark I") was electromechanical, and used odometer-like wheels.
IBM, at least, never made a decimal computer based on voltage
differences. All IBM decimal computers used binary encodings, including:
BCD: 0000 through 1001.
Excess-3: 0011 through 1100
Biquinary: five bits, only one 1, plus two bits, only one 1
Three-of-five: five bits, three 1, and two 0
IBM mainframes still normally use decimal arithmetic for financial
calculations, although binary is used for addressing and scientific
number crunching.
One Russian computer of the 50's used ternary (base-3).
--
John W. Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
-- Charles Williams. "Taliessin through Logres: Prelude"
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> [...]
>> You do not look very smart ignoring this very simple fact repeatedly,
>> while rambling and patronizing knowledgeable people about quite
>> irrelevant possible implementations of data storage in hardware.
>> Nuff said.
>
> Play the ball, not the person, Thomas.
I am playing the ball. I am criticizing (your) evading behavior in
discussions that can be perceived as trolling, as it tries to keep
off-topic discussions alive by posting irrelevant facts and later
stating them as irrelevant repeatedly, while ignoring the real facts
presented, and not having the potential to provide a noticeable gain
to anyone (learning about what is troll behavior aside).
PointedEars
--
When the power of love overcomes the love
of power, the world will know peace.
-- Jimi Hendrix