[ANN] List_Image v0.2.0

[ANN] List_Image v0.2.0

[Lionel Draghi]

List_Image is a small helper to print the content of Ada predefined containers, available here : https://github.com/LionelDraghi/List_Image

The Image generic function returns the image of containers content in various format, customizable at instantiation time, from the simple
  A, B, C

or
  [A, B, C]

or
  - A
  - B
  - C

or
  A, B and C

or more complex format like html :
  <ul>
  <li>A</li>
  <li>B</li>
  <li>C</li>
  </ul> 

Format may differ for empty list and list containing a single item.
So, the same instantiation of the function may return :

- "No test failed"                if the list is empty
- "Test test_1 fails"             if the list contains "test_1"
- "Tests test_1 and test_2 fail"  if the list contains "test_1" and "test_2"

Lionel

Re: [ANN] List_Image v0.2.0

[briot.emmanuel]

> List_Image is a small helper to print the content of Ada predefined containers, available here : https://github.com/LionelDraghi/List_Image


Nice !

And well documented :-)

When I started on the traits containers, I was hoping to create a library of common signature packages that could be reused and built upon in various libraries. Perhaps we could get started on that.

I must admit I never thought of the `Image_Style` traits, but they definitely fit very well.

Some comments on the code:

  * EOL should be defined different when on Windows. I used to test whether the GNAT.OS_Lib.Directory_Separator is '\', perhaps there's a better way nowadays. For sure, a "Is_Windows" constant would be useful somewhere.

     EOL : constant String := (if Is_Windows then ASCII.CR & ASCII.LF else ASCII.LF);

  * Cursors_SIgnature is what I was calling a Forward_Cursor in the traits containers. So there's some code sharing to be done here :-) However, the profile of Has_Element and Next, in my case, was also receiving the container as a parameter, so that they could be compatible with the formal containers distributed with GNAT, and used in SPARK. It is easy to ignore that extra parameter for the standard Ada containers, but not possible to invent it if not given.
For some reason, I was also passing No_Element and "=", but without looking at the code in more details, my first thought now is that these should not be there, so your approach is lighter and likely better.

  * It would be more efficient to use GNATCOLL.Strings instead of Unbounded_Strings (a lot more effort was done for performance there), but then it adds a dependency on a third party library. GNATCOLL.Strings is also using some kind of traits-based approach (and I have a version locally that uses traits to decide whether to use atomic counters, non-atomic counters, or no counter at all (and thus no copy-on-write).   Again in the spirit of sharing a signature-based library somewhere

    By the way, using  'Tmp := Tmp & "...";' is inefficient compared to 'Append (Tmp, "...")` so I would recommend the latter.


   * I see you finally gave up on using the iterable as formal parameters. I also had very limited success with that. As a result, the generic algorithms have to be written using explicit cursors, but since they are reused easily, that's not such an issue.

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le 31/01/2018 à 08:27, emmanuel... a écrit :
>> List_Image is a small helper to print the content of Ada predefined containers, available here : https://github.com/LionelDraghi/List_Image
> 
> 
> Nice !
> 
> And well documented :-)

Thanks! :-)

...
> Some comments on the code:
> 
>    * EOL should be defined different when on Windows. I used to test whether the GNAT.OS_Lib.Directory_Separator is '\', perhaps there's a better way nowadays. For sure, a "Is_Windows" constant would be useful somewhere.
> 
>       EOL : constant String := (if Is_Windows then ASCII.CR & ASCII.LF else ASCII.LF);

I defaulted EOL to Windows CRLF, because it's seems to work well on my Linux box also. But note that it can be overridden when instantiating Cursors.
I don't now a standard way to get the good line terminator.

>    * Cursors_SIgnature is what I was calling a Forward_Cursor in the traits containers. So there's some code sharing to be done here :-) However, the profile of Has_Element and Next, in my case, was also receiving the container as a parameter, so that they could be compatible with the formal containers distributed with GNAT, and used in SPARK. It is easy to ignore that extra parameter for the standard Ada containers, but not possible to invent it if not given.

I am always open to Identifiers changes to have a more coherent and comprehensive naming scheme.

For Next and Has_Element, changing the profile would prevent the easy instantiation with Ada containers. 
If we want the same simplicity with another container collection, I suppose there's no way out, we need to provide more versions of this Cursor generic. 

> For some reason, I was also passing No_Element and "=", but without looking at the code in more details, my first thought now is that these should not be there, so your approach is lighter and likely better.

My hesitation was on the Has_Element parameter. 
The code was simpler when using the Length function instead. 
I remembered that for some reason you decided to provide your own Ada.Containers.Count_Type in your Container, so I choose to stick to First/Next/Has_Element instead of First/Next/Length. 
The body code is more complex, but the component has no dependency (except Unbounded_String in the body), and that's better for reusability.

>    * It would be more efficient to use GNATCOLL.Strings instead of Unbounded_Strings (a lot more effort was done for performance there), but then it adds a dependency on a third party library. GNATCOLL.Strings is also using some kind of traits-based approach (and I have a version locally that uses traits to decide whether to use atomic counters, non-atomic counters, or no counter at all (and thus no copy-on-write). Again in the spirit of sharing a signature-based library somewhere

Yes, I prefer to avoid non standard dependencies.
But we could provide an alternate body. 

>      By the way, using  'Tmp := Tmp & "...";' is inefficient compared to 'Append (Tmp, "...")` so I would recommend the latter.

OK, I will update the code.

>     * I see you finally gave up on using the iterable as formal parameters. I also had very limited success with that. As a result, the generic algorithms have to be written using explicit cursors, but since they are reused easily, that's not such an issue.
Yes, this is my conclusion for this POC! :-)

Thanks again Emmanuel for all the useful inputs. 


 

Re: [ANN] List_Image v0.2.0

[briot.emmanuel]

> I defaulted EOL to Windows CRLF, because it's seems to work well on my Linux box also.

Isn't this because you are printing with Ada.Text_IO, which takes care of normalizing end-of-line terminators ? It might not work when using streams, for instance.

> But note that it can be overridden when instantiating Cursors.

Sure, but I think you should aim at having a package that works on multiple platforms, so that users do not have to care about that notion themselves.


> For Next and Has_Element, changing the profile would prevent the easy instantiation
> with Ada containers. If we want the same simplicity with another container collection,
> I suppose there's no way out, we need to provide more versions of this Cursor generic

One possible approach is to have two signature packages: one that takes the
same profile you do (i.e. Has_Element only receives the cursor), and one for which
Has_Element also receives the container. Algorithms would expect the second one,
but the first one would provide an instance of the second. As in:

     generic
          type Container is private;
          type Cursor is private;
          with function Has_Element (Self : Container; C : Cursor) return Boolean;
     package Forward_Cursors is
     end Forward_Cursors;

     generic
          type Container is private;
          type Cursor is private;
          with function Has_Element (C : Cursor) return Boolean;
     package Ada_Forward_Cursors is
          function Has_Element (Self : Container; C : Cursor) return Boolean
               is (Has_Element (C));
          package FC is new Forward_Cursors (Container, Cursor, Has_Element);
     end Ada_Forward_Cursors;

For standard containers, you instantiate Ada_Forward_Cursors, but pass
the "FC" package to the algorithms.
The main drawback is the need for finding good names, in my experience.
But that makes your algorithms compatible with SPARK and its formal
containers. My own experience when writing containers is that in effect it is
much easier to receive the container as a parameter to Has_Element (avoids
the need for unchecked_access to the container in the cursor, as done for
the Ada containers).

> I remembered that for some reason you decided to provide your own
> Ada.Containers.Count_Type in your Container, so I choose to stick to
> First/Next/Has_Element instead of First/Next/Length. 

Length is a notion that might be hard to compute for some containers, so
indeed better not to rely on it if you can.

I believe the reason I was using my own Count_Type was for compatibility
with SPARK and making it easier to prove things.

> Yes, I prefer to avoid non standard dependencies.

GNATCOLL is standard :-)  Just kidding.

Re: [ANN] List_Image v0.2.0

[J-P. Rosen]

Le 31/01/2018 à 22:11, Lionel Draghi a écrit :
> I defaulted EOL to Windows CRLF, because it's seems to work well on
> my Linux box also. But note that it can be overridden when
> instantiating Cursors. I don't now a standard way to get the good
> line terminator.
There is none, for the simple reason that some operating systems have no
physical line terminator. That's why we have a New_Line procedure in
Ada, rather than some special character.

What I do when I need to return strings that span several lines is to
mark the places with LF; when I need to /print/ these strings, I scan
them and call New_Line at the place of the LF.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le jeudi 1 février 2018 10:56:16 UTC+1, J-P. Rosen a écrit :
> Le 31/01/2018 à 22:11, Lionel Draghi a écrit :
> > I defaulted EOL to Windows CRLF, because it's seems to work well on
> > my Linux box also. But note that it can be overridden when
> > instantiating Cursors. I don't now a standard way to get the good
> > line terminator.
> There is none, for the simple reason that some operating systems have no
> physical line terminator. That's why we have a New_Line procedure in
> Ada, rather than some special character.
> 
> What I do when I need to return strings that span several lines is to
> mark the places with LF; when I need to /print/ these strings, I scan
> them and call New_Line at the place of the LF.

Good idea to have portable code.
 
In my case, as the function is returning the image string, but isn't in charge of printing it, it would “pass the buck” to the user.
I could add an helper Put_Image function, but it's not a totally satisfying solution anyway.

My (maybe naïve) view is that we are getting in complex discussions and weird code patterns to solve a pretty simple problem.
A Text_IO.Line_Terminator function, returning LF or CRLF or a null String for those OSes you just mentioned would be a drastic improvement over current situation.

Because of exceptional situations, we are depriving most Ada users of a simple solution to a common problem (probably discussed hundred time in cla, approximatively, I didn’t check ). 
It would be a OK to specify that this function has a platform dependent semantic, that will be specified by implementors (*). Isn’t it already the case, and for much more complex OS dependent functions?

If we can specify a standard Ada.Directories, I can’t imagine Line_Terminator being a problem!   

In the meantime, I understand from that discussion that I can hardly find a clean internal solution to this problem.
The only clean solution I see, is precisely to “pass the bucket” on the user side, by removing the default declaration of EOL, and asking to the user to provide the convenient value. 
Or to have a separate function, with different possible implementations (one being the GNAT dependent proposed by Emmanuel).

Lionel

(*) : we maybe don't even need to specify that the function shall return LF on unix family OSes and CRLF on Windows

Re: [ANN] List_Image v0.2.0

[bozovic.bojan]

https://en.m.wikipedia.org/wiki/Newline

You can see at above link some systems used ASCII.CR as line terminator, IBM System/390 something on its own and OpenVMS no terminator at all, so making Win32 and POSIX only solution is not enough for portability.

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le jeudi 1 février 2018 18:20:05 UTC+1, bozovi...@gmail.com a écrit :
> https://en.m.wikipedia.org/wiki/Newline
> 
> You can see at above link some systems used ASCII.CR as line terminator, IBM System/390 something on its own and OpenVMS no terminator at all, so making Win32 and POSIX only solution is not enough for portability.

Thanks for the reference : Acorn, ZX81... souvenirs, souvenirs! :-)

Ace, the fastest microcomputer in the universe, is missing (http://oldcomputers.net/jupiter-ace.html) 

You missed my point, I don’t want to limit vendors possibilities to Windows and Unix. 
Defining a function, and let vendors specify what is returned on each platform would be an acceptable choice (and almost as easy to implement than the useless System_Name).

That function would probably return LF and CRLF on the mentioned platforms, but I actually don't need to know.

Re: [ANN] List_Image v0.2.0

[bozovic.bojan]

No I completely understand your point but OpenVMS isn't a souvenir yet. Now, I haven't used it, and I don't know if portable EOL character would break something there, I gave 0.02$ worthless or not, but that system was much more used in 80s and 90s, even though we didn't see portable EOL character in Ada 83/95. I hope someone to explain this situation as end of line character in strings is useful.

Re: [ANN] List_Image v0.2.0

[Dennis Lee Bieber]

On Thu, 1 Feb 2018 10:45:09 -0800 (PST), bozovic.bojan@gmail.com declaimed
the following:

>No I completely understand your point but OpenVMS isn't a souvenir yet. Now, I haven't used it, and I don't know if portable EOL character would break something there, I gave 0.02$ worthless or not, but that system was much more used in 80s and 90s, even though we didn't see portable EOL character in Ada 83/95. I hope someone to explain this situation as end of line character in strings is useful.


	And how will this support, say, a file created under Linux, which is
being processed under Windows? One either has to be able to specify the EOL
convention for each file, convert the EOL convention before using the file,
or have the language attempt to determine the EOL convention at run-time
and make the suitable adjustments. In Python, a file opened for "text"
mode, running on Windows, has <lf> in text converted to <cr><lf> during
output -- on Linux, there is no real difference between text and binary,
<lf> is not expanded during output. And if one does not know the
convention, there is "universal newline" mode, which attempts to guess the
convention based upon what is found within the first few blocks of the
file.

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: [ANN] List_Image v0.2.0

[J-P. Rosen]

Le 01/02/2018 à 21:26, Dennis Lee Bieber a écrit :
> 	And how will this support, say, a file created under Linux, which is
> being processed under Windows? One either has to be able to specify the EOL
> convention for each file, convert the EOL convention before using the file,
> or have the language attempt to determine the EOL convention at run-time
> and make the suitable adjustments. In Python, a file opened for "text"
> mode, running on Windows, has <lf> in text converted to <cr><lf> during
> output -- on Linux, there is no real difference between text and binary,
> <lf> is not expanded during output. And if one does not know the
> convention, there is "universal newline" mode, which attempts to guess the
> convention based upon what is found within the first few blocks of the
> file.

Note that at this point, it's no more a language issue. The problem
would be exactly the same in C or whatever. When you say Python does the
right thing, you mean the Python implementation you tried, right? AFAIK
there is no such thing as a Python standard. And if you think of
particular implementations, Gnat does the same thing: it accepts pretty
much any possible line terminator.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [ANN] List_Image v0.2.0

[Randy Brukardt]

"Lionel Draghi" <lionel.draghi@gmail.com> wrote in message 
news:7f5fec97-6ae6-4833-87df-77aac5a8e4ff@googlegroups.com...
...
>You missed my point, I don't want to limit vendors possibilities to Windows 
>and Unix.
>Defining a function, and let vendors specify what is returned on each 
>platform would
>be an acceptable choice (and almost as easy to implement than the useless 
>System_Name).

What would such a function return on OpenVMS, which does not use a character 
to mark New_Line??

                          Randy.

Re: [ANN] List_Image v0.2.0

[Simon Clubley]

On 2018-02-01, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Lionel Draghi" <lionel.draghi@gmail.com> wrote in message 
> news:7f5fec97-6ae6-4833-87df-77aac5a8e4ff@googlegroups.com...
> ...
>>You missed my point, I don't want to limit vendors possibilities to Windows 
>>and Unix.
>>Defining a function, and let vendors specify what is returned on each 
>>platform would
>>be an acceptable choice (and almost as easy to implement than the useless 
>>System_Name).
>
> What would such a function return on OpenVMS, which does not use a character 
> to mark New_Line??
>

It's optional on VMS.

Records in a file can come with or without line terminators on VMS.

If you do have a line terminator, you can have files in various
formats including records terminated with CR and LF or just LF.
IOW, the only way you know on VMS is to look at the RMS attributes
for a specific file.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le vendredi 2 février 2018 01:02:08 UTC+1, Randy Brukardt a écrit :
> "Lionel Draghi"... wrote in message 
> ...
> >You missed my point, I don't want to limit vendors possibilities to Windows 
> >and Unix.
> >Defining a function, and let vendors specify what is returned on each 
> >platform would
> >be an acceptable choice (and almost as easy to implement than the useless 
> >System_Name).
> 
> What would such a function return on OpenVMS, which does not use a character 
> to mark New_Line??
> 
>                           Randy.

Randy, your're asking my compiler vendor opinion, I'll give it to you! :-) 

It's implementation defined! :-)
In the current version of my compiler on OpenVMS, the function returns "", and that it. 
But in the next version, I'll be smarter : I will return CRLF : if the goal is to scan a string where you have yourself inserted the sequence, and then call Put_Line when the sequence is met, it will works better :-). 
Obviously, users should be warned that string that already contains that sequence will be akwardly cut : i'll put it bold in the doc!
 
But seriously, that's an acceptable side effect, considering that most Ada users will never face it.  

----8<---- end of my compiler vendors carreer :-)

I am aware that there is no silver bullet at this level, because we are trying to manipulate multiple lines within a single String : "fatal conceptual constraint error will be raised here!".

The only good solution would be that my Image function returns, not a String, but a list of String, with no line terminator at all, and that generic parameters that are Strings also becomes list of String.

I have to check by trying to specify such an alternate generic, but I expect it will add a lot of complexity for a problem that rarely arise.
Interresting, never te less, and it smells good my favorite fragrance : "conceptual integrity" by Ada.

And what would be the type of that list, that should be simple, efficient and unbounded, sparkable, etc. Look's like we need a "Text" abstraction here (*).
And also another Signature package... 
Seem's to be a fun challenge, I'm on it! :-)

(*) After all, we have a Text_IO package since the origin of Ada, it's time to define what is a Text! 




 

Re: [ANN] List_Image v0.2.0

[Randy Brukardt]

"Lionel Draghi" <lionel.draghi@gmail.com> wrote in message 
news:191ef0a8-865e-49be-baa6-6c5c2d0b55fc@googlegroups.com...
...
>And what would be the type of that list, that should be simple, efficient 
>and
>unbounded, sparkable, etc. Look's like we need a "Text" abstraction here 
>(*).

For what's its worth (probably very little :-), I used a list of unbounded 
strings for that purpose in my Trash-Finder spam filter. If I was doing it 
today, I'd probably use an indefinite vector of type String instead (lets 
Ada handle memory management of the entire thing, not just the individual 
lines, and the overhead would be about the same). A bit clunky to change the 
length of a line (you have to use Replace_Element for that), but otherwise 
about the same as using an Unbounded_String.

(One of the reasons that the spam filter uses Unbounded_Strings was an 
experiment on my part to see how easy/hard it is writing exclusively with 
them. The experiment wasn't very successful.)

>And also another Signature package...
>Seem's to be a fun challenge, I'm on it! :-)

>(*) After all, we have a Text_IO package since the origin of Ada, it's time 
>to define what is a Text!

Yup.

                    Randy.

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le vendredi 2 février 2018 23:40:36 UTC+1, Randy Brukardt a écrit :
> > Look's like we need a "Text" abstraction here. 
> 
> For what's its worth (probably very little :-), I used a list of unbounded 
> strings for that purpose in my Trash-Finder spam filter. If I was doing it 
> today, I'd probably use an indefinite vector of type String instead (lets 
> Ada handle memory management of the entire thing, not just the individual 
> lines, and the overhead would be about the same). A bit clunky to change the 
> length of a line (you have to use Replace_Element for that), but otherwise 
> about the same as using an Unbounded_String.

I haven't given up on that Text package, but to avoid forcing users to pull to much packages (unless standard) with this simple utility, I tried another solution : I moved multi lines declarations to platform dependent child packages named Unix_ and Windows_Predefined_Styles.
 
The choice will still be done explicitly in the user code.
And there is a not so satisfying code duplication.
I check in the Makefile that both package are identical except for the EOL definition and the package Name. But most users will use only one of those packages, and I felt another generic would be too much. YMMV

Next step : back on exploring the "Text" way.

Lionel

PS : the current version https://github.com/LionelDraghi/List_Image is tagged 1.0.0. Sounds strange if you consider that this is a POC. But I try to apply semantic versioning (https://semver.org/), and there is an API change, so, +1. 
And it should already be v3.0.0... 
Not surprising that some developers feel better with calendar versioning (http://sedimental.org/designing_a_version.html)!

Re: [ANN] List_Image v0.2.0

[J-P. Rosen]

Le 12/02/2018 à 00:27, Lionel Draghi a écrit :
> I haven't given up on that Text package, but to avoid forcing users to pull to much packages (unless standard) with this simple utility, I tried another solution : I moved multi lines declarations to platform dependent child packages named Unix_ and Windows_Predefined_Styles.

And of course, you provide a package like:
with Windows_Predefined_Style;
package Predefined_Style renames Windows_Predefined_Style;

and users will use the package Predefined_Style everywhere.

This way, moving to Unix would require changing two words in one file!

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le lundi 12 février 2018 07:57:27 UTC+1, J-P. Rosen a écrit :
> Le 12/02/2018 à 00:27, Lionel Draghi a écrit :
> > I haven't given up on that Text package, but to avoid forcing users to pull to much packages (unless standard) with this simple utility, I tried another solution : I moved multi lines declarations to platform dependent child packages named Unix_ and Windows_Predefined_Styles.
> 
> And of course, you provide a package like:
> with Windows_Predefined_Style;
> package Predefined_Style renames Windows_Predefined_Style;
> 
> and users will use the package Predefined_Style everywhere.

Of course!! :-)

Thank you Jean-Pierre,I'll add it :-)

Lionel

Re: [ANN] List_Image v0.2.0

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

Thank you, the List_Image package is really cool!

I have two points to make:

On Sun, 11 Feb 2018, Lionel Draghi wrote:

> [...] to avoid forcing users to pull to much packages (unless standard) 
> with this simple utility, I tried another solution : I moved multi lines 
> declarations to platform dependent child packages named Unix_ and 
> Windows_Predefined_Styles.

Point 1:

To avoid code duplication, would it not be better to define a single 
generic package Predefined_Styples with a parameter EOL, and then creat 
the same two packages by instantiation in the spec of List_Image, as 
below?

package Windows_Predefined_Styles is new
              Predefined_Styles(EOL => Windows_EOL)

package Unix_Predefined_Styles is new
              Predefined_Styles(EOL => Unix_EOL)

> The choice will still be done explicitly in the user code.

Indeed!

> And there is a not so satisfying code duplication.

That is the problem with two different packages.


Point 2:

The entire approach gets in trouble if you ever generate and store a 
string on windows, but then use Unix to process ist, or vice versa. For 
portability, it might be better to fix an arbitrary line terminator -- LF, 
or CRLF or whatever, as long as it does never ocur as a part of a line 
itself -- and then delegate the problem of properly printing a sequence of 
lines to the user.

Oh, instead of delegating the problem to the user, you could even solve it 
for the user by defining a child package

package List_Image.Text_IO is

   procedure Put_Lines(Lines: String; EOL: String);

end List_Image.Text_IO;

The implementation would "with Ada.Text_IO", and then iterate through the 
individual lines in Lines, calling Ada.Text_IO.Put_Line for each line. If 
EOL="", Put_Lines will assume a single-line represenation and just call 
Ada.Text_IO.Put_Line(Lines);

Unlike your current approach, this would allow implementations to be 
completely independent from the operation system's line termination 
convention.

Of course, the user should always use List_Images.Text_IO.Put_Lines, to 
print the output from List_Images.Image. Calling Ada.Text_IO directly 
would be a compatibility issue. Consequently, you could (re-)define

   type Image_String is new String;

   generic
     with package Cursors is new Cursors_Signature (<>);
     with function Image (C : Cursors.Cursor) return String is <>;
     with package Style is new Image_Style (<>);
   function Image (Cont : in Cursors.Container) return Image_String;

and

   procedure Put_Lines(Lines: Image_String; EOL: String);

Would that make sense to you?

Stefan

--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: [ANN] List_Image v0.2.0

[Lionel Draghi]

Le lundi 12 février 2018 11:57:18 UTC+1, Stefan...@uni-weimar.de a écrit :
> Thank you, the List_Image package is really cool!

Thank you Stefan, what is cool is to read such a feedback!

...
> To avoid code duplication, would it not be better to define a single 
> generic package Predefined_Styples with a parameter EOL, and then creat 
> the same two packages by instantiation in the spec of List_Image, as 
> below?
> 
> package Windows_Predefined_Styles is new
>               Predefined_Styles(EOL => Windows_EOL)
> 
> package Unix_Predefined_Styles is new
>               Predefined_Styles(EOL => Unix_EOL)

Yes, that's perfectly right. That's why I said "I felt another generic would be too much. YMMV". 
So, your mileage vary :-)
OK, I was a bit too lazy, I guess :-) 

> Point 2:
> 
> The entire approach gets in trouble if you ever generate and store a 
> string on windows, but then use Unix to process ist, or vice versa. 

By using the right generic you can generate the both version, whatever is your platform.
That's why I sometimes use "target platform" in the doc, and not "current platform".
As you said, there is a potential problem if generating a string, and using it on a different platform. But this is a seldom problem, often taken into account outside of the program (for example you can change the line terminator with git according to the system where you clone the code). 
Some lib provide automatic conversion functions (cf. the Python discussion in the same thread), but that's out of scope for me here.

After all, you can't do it with Text_IO: there is no Put_Line (Item, File, Format => Windows);
I don't try to be more catholic than the pope :-)  

> portability, it might be better to fix an arbitrary line terminator -- LF, 
> or CRLF or whatever, as long as it does never ocur as a part of a line 
> itself -- and then delegate the problem of properly printing a sequence of 
> lines to the user.
> 
> Oh, instead of delegating the problem to the user, you could even solve it 
> for the user by defining a child package
> 
> package List_Image.Text_IO is
> 
>    procedure Put_Lines(Lines: String; EOL: String);
> 
> end List_Image.Text_IO;
> 
> The implementation would "with Ada.Text_IO", and then iterate through the 
> individual lines in Lines, calling Ada.Text_IO.Put_Line for each line. If 
> EOL="", Put_Lines will assume a single-line represenation and just call 
> Ada.Text_IO.Put_Line(Lines);
> 
> Unlike your current approach, this would allow implementations to be 
> completely independent from the operation system's line termination 
> convention.
> 
> Of course, the user should always use List_Images.Text_IO.Put_Lines, to 
> print the output from List_Images.Image. Calling Ada.Text_IO directly 
> would be a compatibility issue. Consequently, you could (re-)define
> 
>    type Image_String is new String;
> 
>    generic
>      with package Cursors is new Cursors_Signature (<>);
>      with function Image (C : Cursors.Cursor) return String is <>;
>      with package Style is new Image_Style (<>);
>    function Image (Cont : in Cursors.Container) return Image_String;
> 
> and
> 
>    procedure Put_Lines(Lines: Image_String; EOL: String);
> 
> Would that make sense to you?

Yes. Those points where discussed before in the thread. 
It make sense, but instead of just defining a specific Put_Lines procedure, I do a little step further (even if it add some more complexity) :
I intend to define a "Text" abstraction that is a vector of String : and for multi-line styles, I'll use this Text type instead of String.
This way, I don't have to define a specific line terminator, and there is no limitation on what can be in the String.
I'll provide a Put_Text procedure that will call Text_IO.Put_Line on each Text line, and will no more have to care of the EOL definition.

And, BTW, it will also solve the first problem of code duplication.

On the other hand, what will be lost (at first glance) is the ability to provide an output for another platform. But, as I said, I consider this feature not really in the scope, conversion between text format should be done elsewhere. 

Not sure it will end well, but let's see!

Lionel

Semantic versioning (Was: [ANN] List_Image v0.2.0)

[Jacob Sparre Andersen]

Lionel Draghi <lionel.draghi@gmail.com> writes:

> PS : the current version https://github.com/LionelDraghi/List_Image is
> tagged 1.0.0. Sounds strange if you consider that this is a POC. But I
> try to apply semantic versioning (https://semver.org/), and there is
> an API change, so, +1. 

That rule doesn't count when you are in the 0.*.* series.

Greetings,

Jacob
-- 
Statistics is like a bikini - what it shows is very suggestive,
but the most important stuff is still hidden.

Re: [ANN] List_Image v0.2.0

[J-P. Rosen]

Le 01/02/2018 à 16:48, Lionel Draghi a écrit :
> My (maybe naïve) view is that we are getting in complex discussions and weird code patterns to solve a pretty simple problem.

You can check the environment variable OS; apparently, it's defined in
Linux as well as in Windows. And if it's not defined, assume Windows...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: [ANN] List_Image v0.2.0

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 01/02/2018 à 16:48, Lionel Draghi a écrit :
>> My (maybe naïve) view is that we are getting in complex discussions
> and weird code patterns to solve a pretty simple problem.
>
> You can check the environment variable OS; apparently, it's defined in
> Linux as well as in Windows. And if it's not defined, assume Windows...

Might be better to assume macOS! since it's _not_ defined there.

Re: [ANN] List_Image v0.2.0

[Randy Brukardt]

<briot.emmanuel@gmail.com> wrote in message 
news:da6805ff-8429-4ca0-bbb5-f5462040989d@googlegroups.com...
...
>  * EOL should be defined different when on Windows. I used to test
> whether the GNAT.OS_Lib.Directory_Separator is '\', perhaps there's
> a better way nowadays. For sure, a "Is_Windows" constant would be
> useful somewhere.
>
>     EOL : constant String := (if Is_Windows then ASCII.CR & ASCII.LF else 
> ASCII.LF);

Ada defined System.System_Name for this sort of purpose, but since it is a 
constant and it is implementation-defined, it is is of limited use for this 
purpose.

For Janus/Ada, you could use:

     Is_Windows : constant Boolean := (System.System_Name = System.Win32);

...but for the moment, "Win32" is the only constant defined, so you could 
use "True" as well. If we ever resurrected the Linux compiler, then there 
will be another constant again. (There used to be DOS_Ext and MS_DOS 
constants, but we got rid of those years ago.)

Dunno if GNAT does anything useful with this constant or not.

                               Randy. 

Re: [ANN] List_Image v0.2.0

[briot.emmanuel]

> Ada defined System.System_Name for this sort of purpose, but since it is a 
> constant and it is implementation-defined, it is is of limited use for this 
> purpose.

Apparently GNAT uses it to indicate the "compilation system":

   type Name is (SYSTEM_NAME_GNAT);
   System_Name : constant Name := SYSTEM_NAME_GNAT;

So not very useful in our context either.


Apparently, it has no publicly available entity that would provide that information,
either, so a lot of projects simply do:

   Is_Windows : constant Boolean :=
         GNAT.OS_Lib.Directory_Separator := '\';

Does Janus/Ada have a similar directory_separator somewhere ? Seems like this kind of constant should be standard somewhere. Claiming Ada code is portable is nice (and
mostly true), but I believe almost all  multi-platform projects end up with such a
requirement, in practice, if only to properly handle file names.
If thought Ada.Directories might help here, but apparently not.

Emmanuel

Re: [ANN] List_Image v0.2.0

[Randy Brukardt]

<briot.emmanuel@gmail.com> wrote in message 
news:1b89075d-c284-4358-93b9-704e4b079292@googlegroups.com...
...
> Apparently, it has no publicly available entity that would provide that 
> information,
> either, so a lot of projects simply do:
>
>   Is_Windows : constant Boolean :=
>         GNAT.OS_Lib.Directory_Separator := '\';
>
> Does Janus/Ada have a similar directory_separator somewhere ?

It's in the body of Ada.Directories -- not very useful.

You could test the case of the file system 
(Ada.Directories.Name_Case_Equivalence), Unix/Linux is always 
Case_Insensitive. Windows is Case_Preserving unless you are running a POSIX 
file system -- but then you probably would want POSIX line terminators, too.

>Seems like this kind of constant should be standard somewhere. Claiming Ada 
>code is portable is nice (and
> mostly true), but I believe almost all  multi-platform projects end up 
> with such a
> requirement, in practice, if only to properly handle file names.
> If thought Ada.Directories might help here, but apparently not.

The idea of Ada.Directories is that you do all of the file handling through 
it, and you never need to worry about path separators. (Systems like VMS use 
more than a single character.) Similarly, if you do all of your text file 
writing with Text_IO, you use New_Line and it does the right thing. Assuming 
a single character or string is involved is limiting.

If one has a string with multiple lines, it makes the most sense (for 
portable code) to use anything that makes sense, but then use multiple 
Put_Lines to write it (not just one) so that any sort of separator 
(including just a <CR> as on original Macs or some sort of record separator 
aas on some ancient mainframes) will work.

If you just care about Linux and Windows and don't think anything else will 
ever be used (possible, I guess), then test Name_Case_Equivalence and be 
happy. :-)

                                   Randy.

Re: [ANN] List_Image v0.2.0

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> You could test the case of the file system
> (Ada.Directories.Name_Case_Equivalence), Unix/Linux is always
> Case_Insensitive. Windows is Case_Preserving unless you are running a
  ^^^^^^^^^^^^^^^^?
> POSIX file system -- but then you probably would want POSIX line
> terminators, too.

But not if you are using GNAT (GPL or FSF). Bug 80869 refers[1].

macOS will be Case_Preserving (it is possible to set HFS to be case
sensitive, but you're not advised to do so, since loads of applications
won't work).

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869

Re: [ANN] List_Image v0.2.0

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lyh8qzo0jl.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>> You could test the case of the file system
>> (Ada.Directories.Name_Case_Equivalence), Unix/Linux is always
>> Case_Insensitive. Windows is Case_Preserving unless you are running a
>  ^^^^^^^^^^^^^^^^?

Case_Sensitive, of course. My bad.

>> POSIX file system -- but then you probably would want POSIX line
>> terminators, too.
>
> But not if you are using GNAT (GPL or FSF). Bug 80869 refers[1].

That's unfortunate.

You could submit an ACATS test for Name_Case_Equivalence, which would make 
it more obvious to an implementer when it is missing. (I wrote a couple of 
tests for Ada.Directories a few years back, but Name_Case_Equivalence and 
searching aren't covered. Hierarchical_File_Names is covered.)

Back in the day, AdaCore used to say to say that GNAT followed all RM 
Implementation Advice. It's too bad they don't do that any more (vis-a-vis 
Hierarchical_File_Names, etc.). I had an interesting conversation with 
Robert Dewar on the topic when I built the ACATS test, but the ACATS test 
result is OK as not providing the package is allowed.

I note this is probably the only thing that Ada 2005 thing that Janus/Ada 
does that GNAT does not.

> macOS will be Case_Preserving (it is possible to set HFS to be case
> sensitive, but you're not advised to do so, since loads of applications
> won't work).
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80869

Randy.

Re: [ANN] List_Image v0.2.0

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Dunno if GNAT does anything useful with this constant or not.

   type Name is (SYSTEM_NAME_GNAT);
   System_Name : constant Name := SYSTEM_NAME_GNAT;

So, no.

Re: [ANN] List_Image v0.2.0

[Dmitry A. Kazakov]

On 01/02/2018 09:08, Simon Wright wrote:
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>> Dunno if GNAT does anything useful with this constant or not.
> 
>     type Name is (SYSTEM_NAME_GNAT);
>     System_Name : constant Name := SYSTEM_NAME_GNAT;
> 
> So, no.

Good, it is a bad idea anyway. All OS dependencies must be encapsulated 
into package bodies.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de