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: Yannick Duchêne (Hibou57) on 12 May 2010 10:39 Le Wed, 12 May 2010 07:00:14 +0200, J-P. Rosen <rosen(a)adalog.fr> a écrit: > Of course, this assumes an well-formed Ada file. > FYI, there /is/ a scanner in AdaControl, and I never had a problem. > The trick is to check End_Of_Line when needed, and never check > End_Of_File, but handle End_Error instead. This works even for > ill-formed files. This is a common given advice or tip indeed, to have a exception handlers which catch error at end of text files. I even believe this is the most commonly encountered trap with Ada. > And of course, you are welcome to have a look at my scanner in > AdaControl ;-) Lazy programmers, require you gave them the link : http://www.adalog.fr/adacontrol1.htm (teasing Warren) -- pragma Asset ? Is that true ? Waaww... great
From: Dmitry A. Kazakov on 12 May 2010 11:58 On Wed, 12 May 2010 06:16:05 -0700 (PDT), Maciej Sobczak wrote: > On 11 Maj, 23:46, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> Why an Ada program handling texts need to be aware of your system? > > Because it is running on my system. It's a pretty good idea to have > some local awareness. No, that makes the program non-portable and fragile against system modifications. >> Ada.Text_IO provides an OS-independent abstraction of a text. > > The above is not even wrong. Ada.Text_IO cannot even *name* all the > files that I have on my hard drive. That has nothing to do with text. I agree that Ada.Directories is broken. But that is exactly because it lacks the level of abstraction Ada.Text_IO has. (BTW, you cannot enumerate all files with C I/O either) > Even assuming that I can open some file, the whole "abstraction of a > text" is severely limited. I cannot, for example, read the second > paragraph of the third chapter of the book that is in the file. It is necessarily limited here because not every text is a book. >>> Unfortunately, in Ada the formatting and I/O are entangled in Text_IO. >> >> No. See A.10.8(18) and F.3.3. > > Wrong. They do not relate to Text_IO. That is what you asked for, a not entangled formatting. > Even assuming wider context, formatting without I/O is trivial, but I > cannot have I/O without formatting. Why not? > Text_IO gives me both. > But on the other hand, I'm not sure how I/O without formatting would > look like - that would have to be a plain stream. Which means that > your "abstraction of a text" is little more than a bit of formatting > glued on top of a stream. Sure. Stream is unsuitable for text. It does not make sense to format streams. You do it in UNIX, because it lacks texts, because its file system is "untyped". >> The problem of Text_IO is columns. > > Not only. It cannot detect the end of stream without blocking, for > example. That is a property of the stream. Don't use streams as texts. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 12 May 2010 12:03 On Wed, 12 May 2010 13:27:17 +0000 (UTC), Warren wrote: > But the issue I am taking, are machines that define multiples > of a byte. The compiler vendor will choose an appropriate way to handle that. Whether it is natively for the system truncating/expanding or packing/unpacking, which endianness it is, I don't see any reason why the vendor should/could not follow that. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Warren on 12 May 2010 12:52 =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in news:op.vclkbjy9xmjfy8(a)garhos: > Le Wed, 12 May 2010 07:00:14 +0200, J-P. Rosen <rosen(a)adalog.fr> a > �crit: >> Of course, this assumes an well-formed Ada file. >> FYI, there /is/ a scanner in AdaControl, and I never had a problem. >> The trick is to check End_Of_Line when needed, and never check >> End_Of_File, but handle End_Error instead. This works even for >> ill-formed files. > This is a common given advice or tip indeed, to have a exception > handlers which catch error at end of text files. I even believe this > is the most commonly encountered trap with Ada. > >> And of course, you are welcome to have a look at my scanner in >> AdaControl ;-) > Lazy programmers, require you gave them the link : > http://www.adalog.fr/adacontrol1.htm > > (teasing Warren) Heh heh.. I'm not making any lex changes at this point in time. I've got bigger fish to fry. When the dust all settles, I can then go back and choose my [code] fights then. Warren
From: Maciej Sobczak on 12 May 2010 18:14
On 12 Maj, 17:58, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > >> Why an Ada program handling texts need to be aware of your system? > > > Because it is running on my system. It's a pretty good idea to have > > some local awareness. > > No, that makes the program non-portable and fragile against system > modifications. As I already said, I'm OK with this kind of non-portability. It does not bother me that my program will not work on non-existing systems (which effectively includes those obscure systems that you can surely refer to for the sake of example, but that none of us will ever use anyway). I am pragmatic here. > > Even assuming that I can open some file, the whole "abstraction of a > > text" is severely limited. I cannot, for example, read the second > > paragraph of the third chapter of the book that is in the file. > > It is necessarily limited here because not every text is a book. Bingo. So what is a text, really? Ada.Text_IO (similarly to text I/O libraries in other languages) focuses on lines. This is similarly outdated as focusing on columns and really belongs to the same era. When I read the text in my web browser (the most frequently used application for text consumption nowadays), the "lines" are whatever the browser cares to display, which depends on how I scale the window and what font size I select. I can change these properties dynamically and in particular nothing prevents me from opening the same document in several windows, each differently scaled. This means that "lines" is not a property of the data source, it is a property of the display. Yet everybody is dead focused on the concept of text files that are composed of lines. There are no lines, really. If "text" means anything more than a stream on steroids, then it must be recognized to have a much richer structure than just a sequence of lines. Paragraphs, headings, chapters, whatever - these are structural elements of text. But not lines. Lines and columns are artifacts of the teletype printers era - gone long ago. With this in mind, the "text abstraction" as represented by Ada.Text_IO is really a stream on steroids. That's why I don't understand why you put so much stress on distinguish the "text" from the "stream", while the effective distance between them is close to zero. (please don't remind me constantly about filesystems that are based on records - the line-oriented records are long gone with teletype printers and nowadays "filesystems" will store whole files in single records instead, so we are back to streams anyway) > >> The problem of Text_IO is columns. > > > Not only. It cannot detect the end of stream without blocking, for > > example. > > That is a property of the stream. Don't use streams as texts. Translation: Text_IO cannot detect the end of text without blocking. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 |