for S'Image use Func??
in [ADA]
|
Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Maciej Sobczak on 15 May 2010 16:50 On 15 Maj, 10:35, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > Do you want to say that text files are Turing complete? (:-)) Maybe they > are. Maybe they are not. Consider an experiment. Let us generate random > files containing CRs, LFs and other characters. Show the file to several > people asking them to count lines... Wrong, unless you clearly define the meaning of "show". People do not have the ability to consume files in their storage form. The file has to be *rendered* somehow to be accessible to our senses. For example, it has to be *displayed*, for example using a text editor or a web browser - and this is when the whole exercise becomes both trivial and pointless. And if you give me the freedom to choose my rendering scheme, it will be: $ cat -n file.txt > >>> So what is a text, really? > > >> It is not a book. > > > A scientific paper, perhaps? Or a CV? > > A memo, minutes etc. Wrong. I happen to attend meetings which are so long and rich, that their minutes deserve structure. > > If you stick to the concept of "text" as defined by Text_IO > > (completely unstructured sequence of lines), then effectively the only > > use-case that you will cover without problems is... config files. > > + source codes, which nicely covers 90% of my tasks. Fine. You still forgot about log files. :-) > I don't need Ada.Document_IO. Me neither. I'm perfectly OK with the stream I/O. > > The C++ source code is not a text for me. > > Then you shall not use text editors with it. I don't. I use programmer's editors, also known as IDEs, with it. > >>> Translation: Text_IO cannot detect the end of text without blocking. > > >> No, the translation is: stream does not have an end. > > > That's your arbitrary definition and you did not provide any reference > > for it. > > It does not mean that no stream may have it. It is only a negation that > every stream does. I did not say that every stream has an end. I said that Ada.Text_IO cannot discover it without blocking. Whether the stream has an end or not is completely irrelevant to my original statement, but since you decided to mix it into the discussion... > Anyway, if you tried to define the stream end, you could not do in terms of > its elements, You will need some "non-functional," "out-of-band" return > codes, exceptions etc. Yes. > Blocking is just among others. No. Blocking is not a statement about stream. It tells me nothing about the stream and it still blocks my program. It is a useless strategy and not intuitive, as it shows that the stream is being physically consumed as part of what is a purely predicative operation. > You could say: it > ends when blocked. Not very nice, but, in fact, widely used in network > communication protocols. Widely? An example or two, please? -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 16 May 2010 03:48 On Sat, 15 May 2010 13:50:47 -0700 (PDT), Maciej Sobczak wrote: > On 15 Maj, 10:35, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> Do you want to say that text files are Turing complete? (:-)) Maybe they >> are. Maybe they are not. Consider an experiment. Let us generate random >> files containing CRs, LFs and other characters. Show the file to several >> people asking them to count lines... > > Wrong, unless you clearly define the meaning of "show". That is the point! Show is in each other's head. Some would consider single LF as one empty line, others as two, and some as a broken file. > And if you give me the freedom to choose my rendering scheme, it will > be: > > $ cat -n file.txt It does not work under Windows. As you said about VMS, why should I care what a non-existent hobbyist's OS does? (:-)) >>> If you stick to the concept of "text" as defined by Text_IO >>> (completely unstructured sequence of lines), then effectively the only >>> use-case that you will cover without problems is... config files. >> >> + source codes, which nicely covers 90% of my tasks. > > Fine. You still forgot about log files. :-) I don't use UNIX, remember. Our log files are binary. (Trace files are texts.) >> I don't need Ada.Document_IO. > > Me neither. I'm perfectly OK with the stream I/O. Yes, you stream graphical minutes, as you said... >>> The C++ source code is not a text for me. >> >> Then you shall not use text editors with it. > > I don't. I use programmer's editors, also known as IDEs, with it. IDE is a front end to a text editor. You still need a text to print, store, pass to the compiler. >> You could say: it >> ends when blocked. Not very nice, but, in fact, widely used in network >> communication protocols. > > Widely? An example or two, please? Any. You cannot rely on the remote host always sending you graceful disconnect. Many devices we are dealing with don't even have such thing. They just become silent. As a practical example, load some large text page into the browser. Before it completes, in the middle, pull the Etherenet jack out. Observe the stream end! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 16 May 2010 16:56 On 16 Maj, 09:48, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > Wrong, unless you clearly define the meaning of "show". > > That is the point! Show is in each other's head. Some would consider single > LF as one empty line, others as two, and some as a broken file. So now we can come back to our original subject - what is the added value of Text_IO, then? What is the point of abstracting the notion of text, if it "is in each other's head"? Shouldn't stream I/O be enough and leave the rest to everybody's head in this case? > > And if you give me the freedom to choose my rendering scheme, it will > > be: > > > $ cat -n file.txt > > It does not work under Windows. Of course it does. Cygwin is your best friend. > As you said about VMS, why should I care > what a non-existent hobbyist's OS does? (:-)) You shouldn't. > > Fine. You still forgot about log files. :-) > > I don't use UNIX, remember. Our log files are binary. The only thing I can say now is that not only you don't use Unix, but you also don't use plenty of software packages that exist on Windows. > >> You could say: it > >> ends when blocked. Not very nice, but, in fact, widely used in network > >> communication protocols. > > > Widely? An example or two, please? > > Any. You cannot rely on the remote host always sending you graceful > disconnect. Many devices we are dealing with don't even have such thing. > They just become silent. This makes the end of stream indistinguishable from arbitrary delays. Not a good idea. What about the stream of keystrokes? Is the stream finished just because I'm thinking what to type next? > As a practical example, load some large text page into the browser. Before > it completes, in the middle, pull the Etherenet jack out. Observe the > stream end! It is not a stream end, it is a communication error. Guess what - some protocols are wiser than HTTP and can figure that out, which disproves your universal "any" qualifier. As in the majority of such discussion, we don't have a converging thread and we're not likely to come to any conclusion either (and we are long ago far away from the original problem, too). Is it OK to suggest that we should somehow finish? -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 16 May 2010 17:31 On Sun, 16 May 2010 13:56:57 -0700 (PDT), Maciej Sobczak wrote: > On 16 Maj, 09:48, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> Wrong, unless you clearly define the meaning of "show". >> >> That is the point! Show is in each other's head. Some would consider single >> LF as one empty line, others as two, and some as a broken file. > > So now we can come back to our original subject - what is the added > value of Text_IO, then? That you need not count lines by yourself. > What is the point of abstracting the notion of > text, if it "is in each other's head"? It is not. The notion of stream encoding is. > Shouldn't stream I/O be enough > and leave the rest to everybody's head in this case? No, because we count lines differently. Text_IO provides a way to standardize encodings in inferior operating systems. >>> And if you give me the freedom to choose my rendering scheme, it will >>> be: >> >>> $ cat -n file.txt >> >> It does not work under Windows. > > Of course it does. Cygwin is your best friend. Nope, cygwin is a horror. Even much less offending MinGW is. >>> Fine. You still forgot about log files. :-) >> >> I don't use UNIX, remember. Our log files are binary. > > The only thing I can say now is that not only you don't use Unix, but > you also don't use plenty of software packages that exist on Windows. Right, for example MFC, ActiveX among others. >>>> You could say: it >>>> ends when blocked. Not very nice, but, in fact, widely used in network >>>> communication protocols. >> >>> Widely? An example or two, please? >> >> Any. You cannot rely on the remote host always sending you graceful >> disconnect. Many devices we are dealing with don't even have such thing. >> They just become silent. > > This makes the end of stream indistinguishable from arbitrary delays. These systems are more or less real-time. It means that if the delay exceeds the time of service (which is not necessarily microseconds, it could be seconds), then the game is out anyway. > Not a good idea. What about the stream of keystrokes? Is the stream > finished just because I'm thinking what to type next? The operators have HMI. They don't encourage streams, they do GUIs! >> As a practical example, load some large text page into the browser. Before >> it completes, in the middle, pull the Etherenet jack out. Observe the >> stream end! > > It is not a stream end, it is a communication error. Guess what - some > protocols are wiser than HTTP and can figure that out, which disproves > your universal "any" qualifier. Error is the reason why the stream is or considered ended. Note that the browser does not crash. It renders that end, you can see it by scrolling the page down. > As in the majority of such discussion, we don't have a converging > thread and we're not likely to come to any conclusion either (and we > are long ago far away from the original problem, too). > Is it OK to suggest that we should somehow finish? Yes. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Randy Brukardt on 19 May 2010 02:26
"Warren" <ve3wwg(a)gmail.com> wrote in message news:Xns9D747B0528E86WarrensBlatherings(a)188.40.43.245... > Robert A Duff expounded in news:wccd3x7lww8.fsf(a)shell01.TheWorld.com: > >> "Randy Brukardt" <randy(a)rrsoftware.com> writes: >> >>> I actually don't buy the need for the Assert pragma in the first >>> place: such checks are rarely expensive and thus should simply be >>> part of the code always. >> >> If they're not expensive, then you're not using it enough. ;-) >> >> Also, the other advantage of pragma Assert over an Assert >> procedure is that you can put the pragma in declarative parts >> and package specs. > > What I liked is the added convenience of having the > source module and line number reported, without me > having to code for that. Janus/Ada reports that for all exception raises (as well as a complete traceback of calls), and always has (even back on the Z80 CP/M version in 1981), so there isn't any advantage to the pragma over plain Ada code that raises an exception on failure. The only thing that is even remotely complex that the pragma addresses is putting checks in declarative parts (which is not usually a problem with judious use of blocks). Randy. |