"i = i|0"

J

James Kuyper

James said:
[F'up2 comp.lang.javascript]

Noted, and ignored. Explanation in last paragraph.

Noted, and rejected. We are _not_ discussing C anymore.\

Where does this "We" come from? You are, of course, free to discuss
anything you wish. I, however, am still discussing the accuracy of the
connection between the original C code and the JavaScript produced by
Emscripten, a topic for which comp.lang.c is still an appropriate
cross-reference. The minute that this thread ceases to have a valid C
connection, I will also lose interest in it.

....
There is no programming language called â€javascriptâ€, and from that
everything else follows. STFW.

I did indeed search the Web. The Wikipedia page for JavaScript says
"JavaScript (JS) is a dynamic computer programming language". so you'll
have to forgive me for thinking that there might be some truth in that
statement.

There's nothing unusual about Wikipedia being incorrect - but if so,
would you or anyone else who cares about the issue care to correct that
article? If so, how would you correct it?
It is not just about the case, and I wonder which of my comments could have
mislead you to that assumption.

"... newsgroup name is case-insensitive ... You would not talk about “câ€
either, ..."

That's not enough evidence to prove anything, but you were being too coy
to explain what you actually meant, so I was left with having to guess
what you were talking about based upon the limited amount of available
evidence.

....
Only if an ECMAScript implementation of that name is meant. Since there are
now several such ones that differ considerably (I count three major ones;
the fourth name is just marketing), I would prefix them with the vendor name
or engine codename to avoid the ambiguity.

The Wikipedia page for JavaScript says that "JavaScript was formalized
in the ECMAScript language standard ...", which seem to imply that
JavaScript and ECMAScript are both valid terms, possibly referring to
subtly different things.

The OP called it JavaScript, without any prefix. He was talking about
Emscripten. The Emscripten web page
<https://github.com/kripken/emscripten/wiki> also calls what it produces
JavaScript, without any prefix. I don't think I'm competent to judge
whether or not it would be correct to take what they said about
"JavaScript", and treat it as if were an an equivalent statement about
"ECMAScript". Can you confirm that such a conversion would be correct? I
certainly have no basis on which to choose a vendor name to use as a
prefix. Would you care to identify the appropriate vendor?

Do the differences between those different versions of ECMAScript affect
the validity of Emscripten's translation of this C code? If so, how? If
not, there's no point in worrying about which one is being referred to.
 
T

Thomas Richter

Am 12.06.2014 00:20, schrieb Thomas 'PointedEars' Lahn:
First of all, this does _not_ express the C semantics in JavaScript, and
there is no other way. “int†is a *generic* type in C/C++; IIUC, the result
could be a 32-bit integer when compiled for a 32-bit platform or a 64-bit
integer when compiled for a 64-bit platform.

Not quite. int is a type whatever the compiler chooses it to be, let it
be 32 bit, 64 bit or 36 bit, no matter what the platform is. I have seen
platforms were int was a 16 bit type even tough the platform was 32 bit
wide.

IOWs, the C to JavaScript compiler can surely implement a valid C model
on top of JavaScript with 32 bit ints, the decision to have ints 32 bit
wide is not invalidated by the platform having any other native register
size.
By contrast, using the binary bitwise OR operator, as with all ECMAScript
binary bitwise operators, *always* creates an IEEE-754 double-precision
*floating-point* value representing a *32-bit* integer value. Also, not
only the result will be such a value, but also the operands are converted
to such values internally, before the operation is performed.

Within the limits of what JavaScript has to offer, this is the closest
it can do to emulate the C type system when operating on signed
datatypes; these are also first converted to int (here emulated as 32
bit types), then the operation is performed. It can get very tricky to
emulate the *unsigned* types, and I wonder what the C to JavaScript
compiler would do about them.

Conversion to an integer value of the ECMAScript Number type (i.e., where
the fractional part of the mantissa is zero), which appears to be the goal
here, can be better achieved with the Math.floor() and Math.ceil()
functions, e.g.:

No, I don't think that this is the goal here, i.e. rounding to an
integer number (avoiding the term "int" here intentionally). An "int"
has undefined behavior if an operation overflows. Just rounding would
create another integer number, but one that is outside of the bit range,
possibly with even weirder side effects in the program. That's possibly
not quite what was intended. In the end, it probably does not matter
much because, as said, C leaves it undefined what happens on overflow of
the signed types, and the implementation just picked the simplest
possible choice to create a "round to zero".
Of course, this still does not remotely implement the C semantics. One
aspect of it is that code where you pass a non-integer would not compile.

Not so. Instead, C would truncate the non-integer to the next integer
(cut off the fractional part) and would use that as input. The following
compiles fine:

int plusone(int x)
{
return x+1;
}

int main(int argc,char **argv)
{

return plusone(2.2);
}

I'm not sure how JavaScript handles negative values when applied to the
binary or operator, but I would suspect that it also performs a "round
to zero", which is exactly what C does, thus a perfect match. That is
possibly even intentional in JavaScript.
Since ECMAScript uses dynamic type-checking, it is not possible to prevent
compilation. But at the very least passing unsuitable values should cause
an exception to be thrown, so that it becomes unnecessary to handle them,
e.g.:

Certainly not, since C does not have exceptions either. You could do
that possibly on overflow (with an impact on runtime performance), but
not on passing in a non-integer though numeric type.

Greetings,

Thomas
 
T

Thomas 'PointedEars' Lahn

[F'up2 comp.lang.javascript]

James Kuyper wrote in comp.lang.c:
James said:
On 06/12/2014 08:45 AM, Thomas 'PointedEars' Lahn wrote:
[F'up2 comp.lang.javascript]
Noted, and ignored. Explanation in last paragraph.

Noted, and rejected. We are _not_ discussing C anymore.\

Where does this "We" come from? You are, of course, free to discuss
anything you wish. I, however, am still discussing the accuracy of the
connection between the original C code and the JavaScript produced by
Emscripten, a topic for which comp.lang.c is still an appropriate
cross-reference. The minute that this thread ceases to have a valid C
connection, I will also lose interest in it.

Please point out the word or paragraph in your posting that contains or
refers to C code. If you reasonably cannot, you should reconsider.
...

I did indeed search the Web. The Wikipedia page for JavaScript says
"JavaScript (JS) is a dynamic computer programming language". so you'll
have to forgive me for thinking that there might be some truth in that
statement.

First one has to define what “dynamic programming language†means.
There's nothing unusual about Wikipedia being incorrect - but if so,
would you or anyone else who cares about the issue care to correct that
article? If so, how would you correct it?

I would, and I have a long time ago. I am not convinced that further
editing would be worthwhile. The misconception of a single language appears
to be cemented too deeply into the thinking of the general public. Not just
this article, all related lemmata on Wikipedia need a clean-up. But I am
going to edit it again if and when I find the time.
"... newsgroup name is case-insensitive ... You would not talk about “câ€
either, ..."

That refers to the fact that you cannot infer from the newsgroup name the
spelling of the language (or the topics in the newsgroup, which actually is
a standard and several programming languages based on it, along with host-
defined APIs like the DOM that are *not* part of any implementation of the
standard).
That's not enough evidence to prove anything, but you were being too coy
to explain what you actually meant, so I was left with having to guess
what you were talking about based upon the limited amount of available
evidence.

I had not expected the ECMAScript Support Matrix to malfunction this way;
IIRC it had worked yesterday. I also had not expected that you would not
research the newsgroup and the Web more thoroughly before you posted. I
prefer to not repeat myself. Have you tried a Web cache yet? If not, why
not?
...

The Wikipedia page for JavaScript says that "JavaScript was formalized
in the ECMAScript language standard ...", which seem to imply that
JavaScript and ECMAScript are both valid terms, possibly referring to
subtly different things.

The Wikipedia article is wrong there, too. The first Edition of ECMAScript
formalized common features of Netscape JavaScript 1.1 (released 1996-08 with
Netscape 3.0) and Microsoft’s extended copycat of Netscape JavaScript 1.0
that they called JScript 1.0 (released 1996-08 with Internet Explorer 3.0).
The Specification text itself confirms that (any Edition).
The OP called it JavaScript, without any prefix.

Which begs the question which “JavaScript†they are talking about. It is
instead very likely that they have no clue which language(s) they are
talking about.
He was talking about Emscripten. The Emscripten web page
<https://github.com/kripken/emscripten/wiki> also calls what it produces
JavaScript, without any prefix.

Most people do not know what they are talking about, doubly so on this
topic.
I don't think I'm competent to judge whether or not it would be correct to
take what they said about "JavaScript", and treat it as if were an an
equivalent statement about "ECMAScript". Can you confirm that such a
conversion would be correct?

It would not. ECMAScript is the standard; “JavaScript†is contained in the
name of some implementations of it (borrowing from the original). The
standard is very lenient, therefore its implementations can and do differ
greatly if you know where to look.
I certainly have no basis on which to choose a vendor name to use as a
prefix. Would you care to identify the appropriate vendor?

Of the ECMAScript implementations that I would consider “majorâ€, there are
Netscape/Mozilla JavaScript, Google V8 JavaScript and KDE JavaScript that
contain the “JavaScript†name standalone. The original JavaScript, of
course, is Netscape JavaScript, with Mozilla JavaScript as its open-source
free-software successor (at least those parts that are licensed under MPL
2.0 or later). “Internet Explorer JavaScript†is just a Micro$~1 marketing
scam; its real name is Microsoft JScript 9+ (codename “Chakraâ€), supported
by MSHTML 9+.
Do the differences between those different versions of ECMAScript affect
the validity of Emscripten's translation of this C code? If so, how?

There are no versions of ECMAScript. There is the ECMAScript Language
Specification, there are Editions of it, and implementations of those. I do
not know which syntactic features of which Edition of ECMAScript Emscripten
employs, and I suspect code analysis would take long. I am not aware of any
differences in the implementation of the “|†operator that we discussed
here; however, I understand now that the code it generates has little to do
with the actual statements that are being executed (like, “|0†being just a
type marker for asm.js aso.)

Insofar there is doubt whether Emscripten/asm.js would be on-topic here in
the first place (the same as, e.g., there was resistance discussing
CoffeeScript here).
If not, there's no point in worrying about which one is being referred to.

Wrong. The used implementation is defined by the runtime environment.
 
T

Tim Rentsch

I have read this in a World-Wide Web encyclopedia:

For example, given the following C code:

int f(int i) {
return i + 1;
}

Emscripten would output the following JS code:

function f(i) {
i = i|0;
return (i + 1)|0;
}

Do you think that the |0 is necessary to express the
C semantics in JavaScript, or could the speed of the
generated code be improved by omitting it?

Almost certainly it was put in to prevent unexpected or
undesired behavior if called with a non-numeric argument.
For example, in the following code

a = f1( "5" ) - 1;
b = f2( "5" ) - 1;

function f1( i ){ return i+1; }

function f2( i ){ return (i|0)+1; }

only one of the variables a and b will have the value 5.
 
K

Keith Thompson

Thomas 'PointedEars' Lahn said:
Guess again.

I for one am not interested in guessing.

Your previous statement was:

There is no javascript. [0]

You could save a great deal of time and effort by explaining what
you meant by that; one sentence would probably suffice. Keep in
mind that a large part of the audience to which you made that
statement is not familiar with the language that is the main topic
of the comp.lang.javascript newsgroup (I hope that's sufficiently
unambiguous).

If you choose not to explain, that's fine with me; I'm sufficiently
interested to ask for clarification, but not to do further research.
 
T

Thomas 'PointedEars' Lahn

Keith said:
Thomas 'PointedEars' Lahn said:
Guess again.

I for one am not interested in guessing.

Your previous statement was:

There is no javascript. [0]

You could save a great deal of time and effort by explaining what
you meant by that; one sentence would probably suffice.

Because it *certainly* would not, I used the footnote marker to refer to
my work. However, unfortunately and unexpectedly, as of today there are
technical issues that prevent it from being displayed. So I have given some
explanations in the postings in this thread. You chose to ignore them or
were impatient enough to wait for them arriving at your server.

That said, Google and several other Web caches still have a usable version
If you choose not to explain, that's fine with me; I'm sufficiently
interested to ask for clarification, but not to do further research.

Translation: “I don't know and I don't care what you meant, but you are
wrong.â€

This has nothing to do with C. Please stop crossposting (without F'up2).
 
C

Christoph Michael Becker

Keith said:
I for one am not interested in guessing.

Your previous statement was:

There is no javascript. [0]

You could save a great deal of time and effort by explaining what
you meant by that; one sentence would probably suffice. Keep in
mind that a large part of the audience to which you made that
statement is not familiar with the language that is the main topic
of the comp.lang.javascript newsgroup (I hope that's sufficiently
unambiguous).

That is explained in the NG's FAQ[1] (emphasis mine):

| The comp.lang.javascript newsgroup deals with *ECMAScript languages*,
| so any questions about JavaScript or JScript are welcome.

In chapter 2 the FAQ says:

| The term "javascript" is used as a common name for all dialects of
| ECMAScript.

However, this statement is changed in the revised FAQ[2]:

| For historical reasons, the term “javascript†is used herein as a
| shorthand for “ECMAScript-based programming languagesâ€. Note that not
| all uses of that term here are correct. For example, there are
| instances where using “DOM†instead would have been correct. This
| will be fixed in a later revision.

I agree that it is preferable to eschew the term "javascript" to avoid
potential confusion.

[1] <http://www.jibbering.com/faq/>
[2] <http://pointedears.de/scripts/faq/cljs/>
 
K

Kaz Kylheku

Keith Thompson wrote:
| For historical reasons, the term “javascript†is used herein as a
| shorthand for “ECMAScript-based programming languagesâ€. Note that not
| all uses of that term here are correct. For example, there are
| instances where using “DOM†instead would have been correct. This
| will be fixed in a later revision.

I agree that it is preferable to eschew the term "javascript" to avoid
potential confusion.

monster.com search for "JavaScript":

631 JavaScript jobs matched your search

monster.com search for "ECMAScript"

*crickets*

careers.stackoverflow.com search for "JavaScript"

932 jobs for "JavaScript"

careers.stackoverflow.com search for "ECMAScript"

2 jobs for ECMAScript

It's safe to say that pretty much nobody in the real world gives a **** about
"ECMAScript".

Brendan Eich: "ECMAScript was always an unwanted trade name that sounds like a
skin disease".

Amen.
 
C

Christoph Michael Becker

Kaz said:
monster.com search for "JavaScript":

631 JavaScript jobs matched your search

monster.com search for "ECMAScript"

*crickets*

careers.stackoverflow.com search for "JavaScript"

932 jobs for "JavaScript"

careers.stackoverflow.com search for "ECMAScript"

2 jobs for ECMAScript

It's safe to say that pretty much nobody in the real world gives a **** about
"ECMAScript".

I somewhat agree. That might be the reason for the poor quality of many
JavaScript programs in the wild.
Brendan Eich: "ECMAScript was always an unwanted trade name that sounds like a
skin disease".

Amen.

Fortunately, the name JavaScript is not only a wanted trade name, but
also avoids any confusion about JavaScript being a scripted variant of
Java. ;)

[xpost & fup2 comp.lang.javascript]
 
J

James Kuyper

[F'up2 comp.lang.javascript]

James Kuyper wrote in comp.lang.c: ....
Where does this "We" come from? You are, of course, free to discuss
anything you wish. I, however, am still discussing the accuracy of the
connection between the original C code and the JavaScript produced by
Emscripten, a topic for which comp.lang.c is still an appropriate
cross-reference. The minute that this thread ceases to have a valid C
connection, I will also lose interest in it.

Please point out the word or paragraph in your posting that contains or
refers to C code. If you reasonably cannot, you should reconsider.

I can point out two such paragraphs:
The OP called it JavaScript, without any prefix. He was talking about
Emscripten. The Emscripten web page
<https://github.com/kripken/emscripten/wiki> also calls what it produces
JavaScript, without any prefix. I don't think I'm competent to judge
whether or not it would be correct to take what they said about
"JavaScript", and treat it as if were an an equivalent statement about
"ECMAScript". Can you confirm that such a conversion would be correct?

"What they said about JavaScript" refers to comments about the
translation of C code to JavaScript, and is therefore indirectly a
comment about C code. You might object to the indirect nature of that
reference, but it is not possible to answer my question without reading
those comments, understanding the C code contained in those comments,
and being able to comment on how well that C code was translated.

The following, however, is much more directly about C code - it says so
explicitly:
"Do the differences between those different versions of ECMAScript affect the validity of Emscripten's translation of this C code?"

And it is precisely those two paragraphs that are the primary reason for
my message; the rest of the message was just about me responding to your
quibbles.

....
First one has to define what “dynamic programming language†means.

No, actually, I don't. Nothing that I wrote depends for it's correctness
on the precise definition used for the term "programming language". If
you would prefer that I refer to "JavaScript" as an "oompa-loompa"
rather than a "programming language", feel free to read what I've said
with that term used in place of "programming language" - the change
won't affect any of the points I was actually talking about.

....
I would, and I have a long time ago. I am not convinced that further
editing would be worthwhile. The misconception of a single language appears
to be cemented too deeply into the thinking of the general public.

I would not infer that JavaScript is a single language from that
description - I don't know of any computer language that remained
"single" for any significant length of time. Every language I'm familiar
with has been distributed by different vendors, and has gone through
multiple versions from most of those vendors. There may be some
single-vendor languages which have only ever had one release, but I'm
not familiar with any of them.

Very early in my career I was offered a position that would have
required me to learn a language that was only used by that particular
company, and was never intended to be more widely distributed. I turned
down that position, so it doesn't count as a language that I'm familiar
with - but I also doubt that it had only a single release.
That refers to the fact that you cannot infer from the newsgroup name the
spelling of the language

Odd - most of the newsgroups that I'm familiar with that are devoted to
a particular computer programming language do in fact have names that
provide evidence from which you can infer the spelling (other than case)
of the language's name.
I had not expected the ECMAScript Support Matrix to malfunction this way;
IIRC it had worked yesterday. I also had not expected that you would not
research the newsgroup and the Web more thoroughly before you posted.

I didn't choose the newsgroup; I was responding to a message
cross-posted to that group. It's the OP's responsibility, not mine, to
investigate that newsgroup before cross-posting to it. To me, his
decision to cross-post to comp.lang.javascript still seems quite
reasonable - except for the fact that it had the consequence of bringing
you into this discussion.
I
prefer to not repeat myself. Have you tried a Web cache yet? If not, why
not?

I had thought you had already (finally!) explained yourself, in the very
same message where you mentioned using a Web cache, so there didn't seem
any point in checking out your web site. It still displays as a blank page.

....
Which begs the question which “JavaScript†they are talking about. ...

It doesn't "beg" the question. That is precisely the question I was
asking you down below. These comments are part of the background for
that question.
Of the ECMAScript implementations that I would consider “majorâ€, ...

This isn't about the "major"ness of the vendor - it's about the
correctness of the statements made by the OP and the Emscripten web
site. Do you know which vendor's names could be inserted into those
statements as a prefix before "JavaScript", in order to make them
correct? Do you know which names would render them incorrect? Unless you
know of some names that would fall into each category, there doesn't
seem to be any point in criticizing them for failing to specify the
vendor. And there's certainly no point in criticizing me for failing to
insert the vendor name that they failed to insert in the comments I was
responding to.
There are no versions of ECMAScript. There is the ECMAScript Language
Specification, there are Editions of it, and implementations of those.
....

Your "response" just quibbled about my use of the term "version",
without actually answering the question. To address that quibble, in
light of your response, replace "versions of ECMAScript" with
"implementations of different Editions of ECMAScript".
Wrong. The used implementation is defined by the runtime environment.

We only get to that "if not" clause if the you claim that the "if so"
clause doesn't apply. You didn't actually answer that question, so I
don't know whether you're claiming that "if so" or "if not" is the
relevant clause.

If you are claiming that "if not" is the relevant clause, I don't see
why the statement you've made is relevant to your conclusion that what I
said is wrong. If "the differences between the different implementations
of the different Editions of ECMAScript" do not "affect the validity of
Emscripten's translation of the C code", and the validity of that
translation is the sole question being raised, why would it matter that
"The used implementation is defined by the runtime environment."? That
comment just seems like a non-sequitur.
 
G

glen herrmannsfeldt

(snip)
First one has to define what ???dynamic programming language??? means.

It turns out not what I thought the first time I heard the term,
it is NOT a language in which to write dynamic programming
algorithms. (I wonder what one of those would be called.)

-- glen
 
K

Kaz Kylheku

First one has to define what “dynamic programming language†means.

Very easy. A dynamic programming language is characterized by late binding
features. For instance, type is principally a run-time property of
values/objects, rather than of pieces of program source code. Functions and
types may defined and redefined while the program is running. These
capabilities would be a bare minimum. Dynamic languages also usually exhibit
introspection: various entities that describe the program, and which disappear
after compile time in static languages tend to be available in a useful
run-time representation in dynamic languages. For instance "class"
or "variable name" might be strictly compile-time concepts in a static
language, but in a dynamic language they might be run-time values of some
sort.
 
K

Kaz Kylheku

I somewhat agree. That might be the reason for the poor quality of many
JavaScript programs in the wild.

Here is an issue. ECMAScript insinuates that the language is a standard
dialect. What do you call a dialect which consists of ECMAScript, plus
some implementation-specific extensions?

If you call that ECMAScript, it is misleading, because uses features that are
not described in any Ecma standard.

With a normal language name that doesn't incorporate a standards organization
acronym, we don't have a problem.

For instance we say that we are working in C++ (where most of othe code is
ISO C++, and parts are GNU C++).

The generic name C++ usefully refers to the whole family of dialects.

It is the case with numerous languages; Lisp, Fortran, Pascal, you name it.

As soon as you qualify the name with the name of a standards organization, like
"ISO C++", it cannot clearly refer to the dialect family any more.

In their feverish zeal to have a famous "Script" language named after
their god-forsaken organization, the Eurotards responsible for this farce
clearly didn't pause for a second to think a little bit.
 
C

Christoph Michael Becker

Kaz said:
Here is an issue. ECMAScript insinuates that the language is a standard
dialect.

Only to those who do not care to read the introduction of the language
specification[1]. And that is exactly the point: many who speak of
"javascript" do not even know, that there is a language specification.
It seems appropriate to make them aware.
What do you call a dialect which consists of ECMAScript, plus
some implementation-specific extensions?

I'd call it a conforming ECMAScript implementation.
If you call that ECMAScript, it is misleading, because uses features that are
not described in any Ecma standard.

The ECMAScript standard explicitely allows such extensions in section 2.
With a normal language name that doesn't incorporate a standards organization
acronym, we don't have a problem.

If loosing clarity is not a problem.
For instance we say that we are working in C++ (where most of othe code is
ISO C++, and parts are GNU C++).

The generic name C++ usefully refers to the whole family of dialects.

It is the case with numerous languages; Lisp, Fortran, Pascal, you name it.

Lisp is a good example, as that spans Lisp 1.5 and Scheme (besides
others); two dialects (one may call it two languages) with rather
different semantics. A program that runs on both dialects, could have
completely different outcome. Would it be wise to ask: "I have a Lisp
program; can you please explain what it is doing?"
As soon as you qualify the name with the name of a standards organization, like
"ISO C++", it cannot clearly refer to the dialect family any more.

Unless otherwise defined, see above.
In their feverish zeal to have a famous "Script" language named after
their god-forsaken organization, the Eurotards responsible for this farce
clearly didn't pause for a second to think a little bit.

You may consider catching up on JavaScript/ECMAScript's history before
making such claims.

[1] <http://www.ecma-international.org/ecma-262/5.1/>
 
S

Stephen Sprunk

In their feverish zeal to have a famous "Script" language named
after their god-forsaken organization, the Eurotards responsible for
this farce clearly didn't pause for a second to think a little bit.

ITYM "in their rush to take Microsoft's money in return for helping to
extract them from their Java trademark infringement suit ..."

Does ECMA do _anything_ useful, or are they just another puppet of Intel
and/or Microsoft? I'd never heard of them prior to the ECMAScript
nonsense, and I've never heard of them since.

S
 
S

Stefan Ram

Christoph Michael Becker said:

The LISP 1.5 programmer's manual (1962) writes the language
thus: »LISP«. (I am not sure whether you refer to that
language LISP 1.5, or whether »Lisp 1.5« is something else.)

BTW, JavaScript is the scripting language of

- Mozilla (Netscape) (trademark used by permission of
Oracle (Sun)), and

- Java SE 8 (trademark used by Oracle itself).

I am not aware of any other party that has the permission
of Oracle to use »JavaScript« for a programming language.
 
G

glen herrmannsfeldt

(snip)
Does ECMA do _anything_ useful, or are they just another puppet of Intel
and/or Microsoft? I'd never heard of them prior to the ECMAScript
nonsense, and I've never heard of them since.

You can also get free copies of many other standards that are
expensive the normal way. I believe I first found out about
them looking for QIC (quarter inch tape) standards.

(I don't remember that QIC was expensive, though.)

-- glen
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top