A
Arne Vajhøj
It seems pretty meaningful to show that you yourself wrote
what you asked about who wrote!
Arne
Reading LAST line from text file without iterating through the file?
It seems pretty meaningful to show that you yourself wrote
what you asked about who wrote!
Arne
T
Tom Anderson
Practically all non-smartphones do, i think. My understanding (gained from
looking at the wikipedia article on smartphones) is that about 20% of
phones in first-world countries are smartphones, and that very roughly
speaking, a third of smartphones are Android, a third Symbian, a sixth
iOS, and a sixth BlackBerry. Symbian and BlackBerry support J2ME; iOS and
Android don't. So, about 10% of mobile phones in the first world don't
support J2ME. I think that's enough that it's not 'practically all'.
Particularly since market share is apparently calculated by dollars, not
units, in which case the market share of non-J2ME phones is very
significantly greater than 10%.
tom
A
Arved Sandstrom
On 11-02-27 04:19 PM, Arne Vajhøj wrote:
[ SNIP ]
I had to read that last two or three times before I got it.
The
surprise isn't so much over the fact that an OpenVMS Java can deal with
a stream of lines (which after all _is_ a text file), but rather over
the fact that the VMS developers managed to slot this record format in
which the other record format types?
AHS
[ SNIP ]
I had to read that last two or three times before I got it.
Thesurprise isn't so much over the fact that an OpenVMS Java can deal with
a stream of lines (which after all _is_ a text file), but rather over
the fact that the VMS developers managed to slot this record format in
which the other record format types?
AHS
A
Arne Vajhøj
You have not figured out that your iPhone apps market if 100% iPhone
and 0% anything else may not be representive for all markets?
That's very fascinating, Arne, but it does not alter the fact that they
can cope just fine with ASCII text files.
No. That is "backwards compatibility".
Arne
W
Wojtek
Lew wrote :
You must have missed reading the line:
"To get binary information you need to have an encoding standard, which
is itself 7-bit."
For instance UU-ENCODE
You must have missed reading the line:
"To get binary information you need to have an encoding standard, which
is itself 7-bit."
For instance UU-ENCODE
A
Arne Vajhøj
OK - that is true.
But none of the mobile phones you mention without Java ME fell
in the category where you can not get apps.
Arne
PS: You can run Java ME apps on Android by adding a ME
toolkit, but it does not really count, because it is
not provide for or supported by Google.
A
Arne Vajhøj
On 11-02-27 04:19 PM, Arne Vajhøj wrote:
[ SNIP ]
I had to read that last two or three times before I got it.
surprise isn't so much over the fact that an OpenVMS Java can deal with
a stream of lines (which after all _is_ a text file), but rather over
the fact that the VMS developers managed to slot this record format in
which the other record format types?
Yes.
The program Ken provided is very stream oriented and not that
easy to get to fit with something record oriented.
And Java is a hard problem for this stuff, because:
1) the Java API itself is stream oreiented
2) the API is completely standardized (in Fortran, Pascal,
C etc. they just added options to OPEN, open, fopen to
support all the possibilities)
Arne
M
Mike Schilling
Ken Wesson said:No, sophistry. You can't use a superset of ASCII without using ASCII, any
more than you can take a bath in soapy water without using water.
No - I didn't.
I didn't say they used *only* ASCII.
Don't be silly. If I write software that uses TCP/IP does that mean it
does not support any communication protocols other than TCP/IP? What if
it directly sends serial port commands to /dev/lpt0 as well as using TCP/
IP? Uh-oh! According to Arne such software is impossible! And yet I note
that there are web browsers that can both surf and print. Some can even
do them at the same time.
Yes, you were! You even did it again, above.
I think I'm getting close to the point of plonking you, Arne. When you're
not barking at me like some rabid wolf you're mainly engaging in shallow
forms of intellectual dishonesty such as the above.
Nonsense.
If you try to read as ASCII file as if it were UTF-8, you'll see the right
characters: compatible.
If you try to read as ASCII file as if it were UTF-16, you'll see garbage:
incompatible.
M
Mike Schilling
Arne Vajhøj said:
It's not that hard, really. You open and manipulate the file with RMS,
which takes care of the record format. On write, you translate every LF to
"end current record", while on read you translate the end of every record to
an LF in what's returned. I've done similar things in C or C++ code that
has to be portable among different OS's. (The tricky bit is (or used to be)
writing binary bag-of-bytes files on VMS. For Unix compatibility, they need
to know exactly how long they are, which may be an odd number of bytes, but
RMS can't write files that aren't an even number of bytes, so you've got to
use the XQP to update the file's length after RMS has closed it. At least,
that was true back in the early 90s.)
M
Martin Gregorie
But does write() put the \r back in Windows? I don't have a suitable
windows box to check it on. If it does this it's merely implementing good
cross-platform portability, which I'd expect from any current language:
even C translates the external representation of \n to suit the platform
its running on.
A
Arne Vajhøj
No.
But per convention then ASCII means only ASCII.
If you set the charset to ASCII in a Content-Type
and the content is actually UTF-8, then you will
get errors.
Don't be silly. If I write software that uses TCP/IP does that mean it
does not support any communication protocols other than TCP/IP? What if
it directly sends serial port commands to /dev/lpt0 as well as using TCP/
IP? Uh-oh! According to Arne such software is impossible! And yet I note
that there are web browsers that can both surf and print. Some can even
do them at the same time.
That is not particular relevant.
No one has implied that because a computer uses UTF-8, then it
did not have a browser or could not print or anything similar.
Read again.
Do you need technical assistance on how to add me to the
killfile in your newsreader?
Try it.
If you read UTF-16 as ASCII you get lots of extra nuls.
(and if the program is a C program then that is a big problem)
Arne
A
Arne Vajhøj
It is a bit more complex than that. Because the line contained a LF.
It works naturally in languages like Fortran, Pascal, Cobol.
In languages like C or Java that are stream oriented and even
may have special meaning for LF, then it becomes a bit messy.
For Java on VMS the recommendation is to use stream_lf files
instead of variable length files.
It is simpler.
But they have added some support for the other types to
be able to work with other stuff.
Little has changed with RMS and SYS$QIO(W) since then.
Arne
A
Arne Vajhøj
It does.
Yes.
And Python probably just inherited it from C.
Arne
L
Lew
Up until "Ken Wesson" started trolling.
No, he just pulled the same stuff under different aliases, no doubt, or else
he was busy being an idiot somewhere else.
Given all the fantasies and flat-out baloney that "Ken Wesson" claims to
remember, I wouldn't believe this claim either. at least not just because he
claims it. I've been using cljp long enough to know what the truth is, anyway.
Personally I think he just lies and makes up stuff in order to argue. Of
course, I'm only reading the snippets people quote, so it's remotely possible
I need a larger sample. I only have a 99.99% confidence level.
No, he just pulled the same stuff under different aliases, no doubt, or else
he was busy being an idiot somewhere else.
Given all the fantasies and flat-out baloney that "Ken Wesson" claims to
remember, I wouldn't believe this claim either. at least not just because he
claims it. I've been using cljp long enough to know what the truth is, anyway.
Personally I think he just lies and makes up stuff in order to argue. Of
course, I'm only reading the snippets people quote, so it's remotely possible
I need a larger sample. I only have a 99.99% confidence level.
B
Bent C Dalager
I still think people should have let me keep containing him in the
Great SWT Program thread. It may have been ugly, but at least it was
only ugly in one single thread which could then be killfiled.
Cheers,
Bent D
A
A Lurker
Whoa, whoa, TIME OUT.
This is getting out of hand. How did a simple debate about text file
formats turn into this mess?!
Ken, Tom -- Obviously, reasonable people may disagree on where the
boundary between text files and everything else lies.
Everyone that's flaming -- There's no need for making things personal
and disparaging one another just because you disagree on where to draw
the line between text and binary files.
I note that most of the flaming is directed at Ken and contains some
outlandish assertions.
* "Ken is not keeping his cool". Ken seems to be keeping his cool more
than at least two or three of the other participants, though that last
round of replies replacing quoted material with "bark bark bark!" is a
little bit dubious in that regard.
* "Ken is not a programmer". I think
http://groups.google.com/group/clojure/msg/912f8570aa350e99 suffices to
disprove that claim, unless you're going to start throwing around
conspiracy theories that his posts to that group are all ghost-written
by somebody else.
* "Ken is a troll". I checked Ken's history in this group and until
recently he was making the occasional, mostly unnoticed constructive
contribution. He only seems to have started generating dozens or
argumentative posts when people started being unpleasant to him for
whatever reason. The flashpoints being things like that "lmgtfy.com"
link and similar instances where Ken said something that seems perfectly
reasonable to me and someone's response was less than 100% technical,
on-point, and devoid of personal insinuations regarding Ken.
* The more outlandish conspiracy theories raised in the past 24 hours
aren't even worth consideration. The ONLY thing Ken has in common with a
certain past cljp poster seems to be a refusal to let someone else have
the last word if that word is interpreted as a personal attack or as
otherwise wrong. And he clearly has that in common with Arne, among
other people here, as well.
Also, His post headers look nothing like that other poster's; he
apparently sometimes uses vi on unix workstations and that other poster
hates vi; he apparently does a lot of coding in Lisp and that other
poster hates Lisp; and so on, and so forth.
So, it seems like further trouble can be avoided if:
1. Ken tries not to make that big a deal out of minor insinuations such
as lmgtfy links.
2. Everyone else avoids making personal comments about Ken, or implying
same. In fact, everyone should be avoiding making or insinuating
personal comments about everyone else anyway, because as Ken has
pointed out that is not the topic of this newsgroup.
3. With regard to the three threads currently ablaze, everyone just
shut up. Let Ken have the last word -- that seems fairer than the
other options, as it's likely Ken will just make a few parting
remarks about his definition of text vs. binary files, replace a
few more quoted non-Java-related passages with "bark bark bark!",
and say a couple of more times that this is a Java newsgroup and
not a calling-people-names newsgroup and then drop it.
Whereas just about anyone else getting the last words in will
probably make them "Ken is a troll" or something similarly less
desirable from the standpoint of topicality.
Also, since the first (albeit weak) jabs were thrown at Ken, it
seems only fair to let Ken get an equal number of responses.
This may sound an awful lot like it boils down to "let Ken win", and
actually it basically is, but in my opinion with good reason: Ken has
tried to stick to the technical matters and has mostly avoided
namecalling and similar behaviors, though he might have been better
served just trimming the namecalling of others silently than calling
more attention to it and replacing it with "bark bark bark!", whereas
almost everyone else (except Tom and maybe Arved) has been caught
flaming. I'd say they clearly ceded Ken the moral high ground by doing so.
On the technical merits, call it a draw. By Ken's fairly sensible
definition of text files, the record-oriented files on the mainframes
aren't text files. By other definitions (say, "a file format whose
primary purpose is to store text", they are. Ken makes a valid point
that these files can be used to store information that will not be
representable in common in-memory string formats, including
java.lang.String; a valid counterpoint is that this would be a quite
unusual use of the files, and in non-pathological cases the files can be
processed by normal text-file-handling tools without loss. One could
even make the argument that Ken's argument is analogous to "because JPEG
compression would clobber information steganographically encoded in the
low bits of the color channels of the pixels of a raster, JPEG and other
lossy non-raster image formats aren't true picture files".
This is getting out of hand. How did a simple debate about text file
formats turn into this mess?!
Ken, Tom -- Obviously, reasonable people may disagree on where the
boundary between text files and everything else lies.
Everyone that's flaming -- There's no need for making things personal
and disparaging one another just because you disagree on where to draw
the line between text and binary files.
I note that most of the flaming is directed at Ken and contains some
outlandish assertions.
* "Ken is not keeping his cool". Ken seems to be keeping his cool more
than at least two or three of the other participants, though that last
round of replies replacing quoted material with "bark bark bark!" is a
little bit dubious in that regard.
* "Ken is not a programmer". I think
http://groups.google.com/group/clojure/msg/912f8570aa350e99 suffices to
disprove that claim, unless you're going to start throwing around
conspiracy theories that his posts to that group are all ghost-written
by somebody else.
* "Ken is a troll". I checked Ken's history in this group and until
recently he was making the occasional, mostly unnoticed constructive
contribution. He only seems to have started generating dozens or
argumentative posts when people started being unpleasant to him for
whatever reason. The flashpoints being things like that "lmgtfy.com"
link and similar instances where Ken said something that seems perfectly
reasonable to me and someone's response was less than 100% technical,
on-point, and devoid of personal insinuations regarding Ken.
* The more outlandish conspiracy theories raised in the past 24 hours
aren't even worth consideration. The ONLY thing Ken has in common with a
certain past cljp poster seems to be a refusal to let someone else have
the last word if that word is interpreted as a personal attack or as
otherwise wrong. And he clearly has that in common with Arne, among
other people here, as well.
Also, His post headers look nothing like that other poster's; he
apparently sometimes uses vi on unix workstations and that other poster
hates vi; he apparently does a lot of coding in Lisp and that other
poster hates Lisp; and so on, and so forth.
So, it seems like further trouble can be avoided if:
1. Ken tries not to make that big a deal out of minor insinuations such
as lmgtfy links.
2. Everyone else avoids making personal comments about Ken, or implying
same. In fact, everyone should be avoiding making or insinuating
personal comments about everyone else anyway, because as Ken has
pointed out that is not the topic of this newsgroup.
3. With regard to the three threads currently ablaze, everyone just
shut up. Let Ken have the last word -- that seems fairer than the
other options, as it's likely Ken will just make a few parting
remarks about his definition of text vs. binary files, replace a
few more quoted non-Java-related passages with "bark bark bark!",
and say a couple of more times that this is a Java newsgroup and
not a calling-people-names newsgroup and then drop it.
Whereas just about anyone else getting the last words in will
probably make them "Ken is a troll" or something similarly less
desirable from the standpoint of topicality.
Also, since the first (albeit weak) jabs were thrown at Ken, it
seems only fair to let Ken get an equal number of responses.
This may sound an awful lot like it boils down to "let Ken win", and
actually it basically is, but in my opinion with good reason: Ken has
tried to stick to the technical matters and has mostly avoided
namecalling and similar behaviors, though he might have been better
served just trimming the namecalling of others silently than calling
more attention to it and replacing it with "bark bark bark!", whereas
almost everyone else (except Tom and maybe Arved) has been caught
flaming. I'd say they clearly ceded Ken the moral high ground by doing so.
On the technical merits, call it a draw. By Ken's fairly sensible
definition of text files, the record-oriented files on the mainframes
aren't text files. By other definitions (say, "a file format whose
primary purpose is to store text", they are. Ken makes a valid point
that these files can be used to store information that will not be
representable in common in-memory string formats, including
java.lang.String; a valid counterpoint is that this would be a quite
unusual use of the files, and in non-pathological cases the files can be
processed by normal text-file-handling tools without loss. One could
even make the argument that Ken's argument is analogous to "because JPEG
compression would clobber information steganographically encoded in the
low bits of the color channels of the pixels of a raster, JPEG and other
lossy non-raster image formats aren't true picture files".
P
Paul Cager
Well, they aren't. The One True image format is PNG. Obviously.
M
Mike Schilling
A Lurker said:
Sure they are. In fact, they were the traditional way to represent text
before the Unix "a file is nothing but a sequence of bytes, with any further
structure imposed on it by the applications that use it" philosophy became
so prevalent. Explicit records are isomorphic with records delimited by
characters (CR, LF, or CR/LF being the popular choices).
J
Joshua Cranmer
No, it's PBM.
P
Paul Cager
I'm not so sure the situation is that black and white.