Deleting a preloaded image from memory

[Richard Cornford]

VK wrote:

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

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

Your opinions are worthless and may as well be kept to yourself.

IYMHO (In Your Most Humble Opinion).

 

[Richard Cornford]

IYMHO (In Your Most Humble Opinion).

My opinion maybe, but a long way from being only my opinion.

Richard.

 

[Randy Webb]

VK said the following on 5/25/2006 7:53 AM:

IYMHO (In Your Most Humble Opinion).

I think it would be safe to add "and at least 100 other peoples opinion"
if not more than 100.

 

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

 

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

 

[Bart Van der Donck]

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.

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.

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

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.

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

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.

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 Van der Donck]

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

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.

 

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


/L

 

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

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.

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

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.

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

 

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

/L

 

[VK]

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.

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]

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

 

[Richard Cornford]

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.

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.

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?

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

Yes, that is correct.


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

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]

Then I would say that you are being irrelevant.

Yes, that is irrelevant to this group.

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.


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.

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

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.

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.

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.

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

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.

 

[Thomas 'PointedEars' Lahn]

Yes, that is irrelevant to this group.

If you can agree with that, why do you not just stop posting off topic?

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

 

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

 

[Randy Webb]

Bart Van der Donck said the following on 5/26/2006 1:54 PM:

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