* Incompatible types for array conversion @ 2015-07-22 1:19 hreba 2015-07-22 5:20 ` Niklas Holsti ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: hreba @ 2015-07-22 1:19 UTC (permalink / raw) I have a generic vector package: generic dim: positive; type Real is digits <>; package Vectors is type Vector is array (1..dim) of Real; function "*" (a: Vector; b: Real) return Vector; end Vectors; In another package I want to model the definition of a (physical) position vector by its direction and module: package Basic is type Real is new Interfaces.IEEE_Float_64; type Length is new Real; package Positions is new Gen.Vectors (3, Length); package Directions is new Gen.Vectors (3, Real); subtype Position is Positions.Vector; subtype Direction is Directions.Vector; function "*" (l: Direction; r: Length) return Position; end Basic; Now my attempt to define this function: function "*" (l: Direction; r: Length) return Position is begin return Positions."*"(Position(l), r); end "*"; gets me the error message in the subject line. Do I have to convert the vector element by element in a loop or is there a more elegant way? -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 1:19 Incompatible types for array conversion hreba @ 2015-07-22 5:20 ` Niklas Holsti 2015-07-22 7:13 ` Simon Wright 2015-07-22 13:00 ` hreba 2015-07-22 6:49 ` Georg Bauhaus 2015-07-23 13:21 ` hreba 2 siblings, 2 replies; 14+ messages in thread From: Niklas Holsti @ 2015-07-22 5:20 UTC (permalink / raw) On 15-07-22 04:19 , hreba wrote: > I have a generic vector package: > > generic > dim: positive; > type Real is digits <>; > package Vectors is > type Vector is array (1..dim) of Real; > function "*" (a: Vector; b: Real) return Vector; > end Vectors; > > In another package I want to model the definition of a (physical) > position vector by its direction and module: > > package Basic is > type Real is new Interfaces.IEEE_Float_64; > type Length is new Real; > > package Positions is new Gen.Vectors (3, Length); > package Directions is new Gen.Vectors (3, Real); > > subtype Position is Positions.Vector; > subtype Direction is Directions.Vector; > > function "*" (l: Direction; r: Length) return Position; > end Basic; > > Now my attempt to define this function: > > function "*" (l: Direction; r: Length) return Position is > begin return Positions."*"(Position(l), r); end "*"; > > gets me the error message in the subject line. > > Do I have to convert the vector element by element in a loop or is there > a more elegant way? The conversion is rejected because of the conversion condition in RM 4.6 (24.5/2): "The component subtypes shall statically match". The component (sub)types are Real and Length, which are different types, although Length is derived from Real. If you change the declaration of Length to be subtype Length is Real; the conversion becomes legal. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 5:20 ` Niklas Holsti @ 2015-07-22 7:13 ` Simon Wright 2015-07-22 7:41 ` Niklas Holsti 2015-07-22 13:00 ` hreba 1 sibling, 1 reply; 14+ messages in thread From: Simon Wright @ 2015-07-22 7:13 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > The conversion is rejected because of the conversion condition in RM > 4.6 (24.5/2): "The component subtypes shall statically match". The > component (sub)types are Real and Length, which are different types, > although Length is derived from Real. If you change the declaration of > Length to be > > subtype Length is Real; > > the conversion becomes legal. I tried generic dim: positive; type Real is digits <>; package Vectors is type Vector is array (1..dim) of Real'Base; but it still failed. (GPL 2015, FSF 5.1.0) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 7:13 ` Simon Wright @ 2015-07-22 7:41 ` Niklas Holsti 2015-07-22 12:32 ` Simon Wright 0 siblings, 1 reply; 14+ messages in thread From: Niklas Holsti @ 2015-07-22 7:41 UTC (permalink / raw) On 15-07-22 10:13 , Simon Wright wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> The conversion is rejected because of the conversion condition in RM >> 4.6 (24.5/2): "The component subtypes shall statically match". The >> component (sub)types are Real and Length, which are different types, >> although Length is derived from Real. If you change the declaration of >> Length to be >> >> subtype Length is Real; >> >> the conversion becomes legal. > > I tried > > generic > dim: positive; > type Real is digits <>; > package Vectors is > type Vector is array (1..dim) of Real'Base; > > but it still failed. (GPL 2015, FSF 5.1.0) Did you expect it to work? Real'Base gets rid of any constraints on Real, but AIUI does not get rid of the type derivation; if "type Length is new Real", Length'Base is not the same as Real'Base -- the "new" makes them different. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 7:41 ` Niklas Holsti @ 2015-07-22 12:32 ` Simon Wright 2015-07-27 23:12 ` Randy Brukardt 0 siblings, 1 reply; 14+ messages in thread From: Simon Wright @ 2015-07-22 12:32 UTC (permalink / raw) Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > On 15-07-22 10:13 , Simon Wright wrote: >> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >> >>> The conversion is rejected because of the conversion condition in RM >>> 4.6 (24.5/2): "The component subtypes shall statically match". The >>> component (sub)types are Real and Length, which are different types, >>> although Length is derived from Real. If you change the declaration >>> of Length to be >>> >>> subtype Length is Real; >>> >>> the conversion becomes legal. >> >> I tried >> >> generic >> dim: positive; >> type Real is digits <>; >> package Vectors is >> type Vector is array (1..dim) of Real'Base; >> >> but it still failed. (GPL 2015, FSF 5.1.0) > > Did you expect it to work? Real'Base gets rid of any constraints on > Real, but AIUI does not get rid of the type derivation; if "type > Length is new Real", Length'Base is not the same as Real'Base -- the > "new" makes them different. Well, who knows what 'statically match' means! (outside the ARG, anyway). I thought it was worth a try. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 12:32 ` Simon Wright @ 2015-07-27 23:12 ` Randy Brukardt 0 siblings, 0 replies; 14+ messages in thread From: Randy Brukardt @ 2015-07-27 23:12 UTC (permalink / raw) "Simon Wright" <simon@pushface.org> wrote in message news:ly1tg0jrtm.fsf@pushface.org... > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: > >> On 15-07-22 10:13 , Simon Wright wrote: >>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >>> >>>> The conversion is rejected because of the conversion condition in RM >>>> 4.6 (24.5/2): "The component subtypes shall statically match". The >>>> component (sub)types are Real and Length, which are different types, >>>> although Length is derived from Real. If you change the declaration >>>> of Length to be >>>> >>>> subtype Length is Real; >>>> >>>> the conversion becomes legal. >>> >>> I tried >>> >>> generic >>> dim: positive; >>> type Real is digits <>; >>> package Vectors is >>> type Vector is array (1..dim) of Real'Base; >>> >>> but it still failed. (GPL 2015, FSF 5.1.0) >> >> Did you expect it to work? Real'Base gets rid of any constraints on >> Real, but AIUI does not get rid of the type derivation; if "type >> Length is new Real", Length'Base is not the same as Real'Base -- the >> "new" makes them different. > > Well, who knows what 'statically match' means! (outside the ARG, > anyway). I thought it was worth a try. It's clearly ;-) explained in ARM 4.9.1. Short summary: it's the same type with the same constraint. We use statically match simply so that things that are "obviously" the same are treated as such: subtype S1 is Int range 1 .. 10; subtype S2 is Int range 1 .. 10; S1 and S2 statically match (as one would hope). But if someone declared separate types in Ada (as in "new"), they're really different, and then they can never statically match (because they don't match in any way). Some other parts of type conversions use "convertible", which would allow such conversions. I think the rules for array components are too strict, but simply using "convertible" doesn't work for various obscure reasons, and coming up with a concept just for this case isn't worth it. (We looked at this as one of the solutions for AI12-0037-1, but in the end we just changed the declarations of the types instead.) Randy. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 5:20 ` Niklas Holsti 2015-07-22 7:13 ` Simon Wright @ 2015-07-22 13:00 ` hreba 2015-07-22 13:22 ` hreba 1 sibling, 1 reply; 14+ messages in thread From: hreba @ 2015-07-22 13:00 UTC (permalink / raw) On 07/22/2015 02:20 AM, Niklas Holsti wrote: > On 15-07-22 04:19 , hreba wrote: >> I have a generic vector package: >> >> generic >> dim: positive; >> type Real is digits <>; >> package Vectors is >> type Vector is array (1..dim) of Real; >> function "*" (a: Vector; b: Real) return Vector; >> end Vectors; >> >> In another package I want to model the definition of a (physical) >> position vector by its direction and module: >> >> package Basic is >> type Real is new Interfaces.IEEE_Float_64; >> type Length is new Real; >> >> package Positions is new Gen.Vectors (3, Length); >> package Directions is new Gen.Vectors (3, Real); >> >> subtype Position is Positions.Vector; >> subtype Direction is Directions.Vector; >> >> function "*" (l: Direction; r: Length) return Position; >> end Basic; >> >> Now my attempt to define this function: >> >> function "*" (l: Direction; r: Length) return Position is >> begin return Positions."*"(Position(l), r); end "*"; >> >> gets me the error message in the subject line. >> >> Do I have to convert the vector element by element in a loop or is there >> a more elegant way? > > The conversion is rejected because of the conversion condition in RM 4.6 > (24.5/2): "The component subtypes shall statically match". The component > (sub)types are Real and Length, which are different types, although > Length is derived from Real. If you change the declaration of Length to be > > subtype Length is Real; > > the conversion becomes legal. > Thanks a lot for the hint! -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 13:00 ` hreba @ 2015-07-22 13:22 ` hreba 2015-07-22 17:50 ` Niklas Holsti 0 siblings, 1 reply; 14+ messages in thread From: hreba @ 2015-07-22 13:22 UTC (permalink / raw) On 07/22/2015 10:00 AM, hreba wrote: > On 07/22/2015 02:20 AM, Niklas Holsti wrote: >> On 15-07-22 04:19 , hreba wrote: >>> I have a generic vector package: >>> >>> generic >>> dim: positive; >>> type Real is digits <>; >>> package Vectors is >>> type Vector is array (1..dim) of Real; >>> function "*" (a: Vector; b: Real) return Vector; >>> end Vectors; >>> >>> In another package I want to model the definition of a (physical) >>> position vector by its direction and module: >>> >>> package Basic is >>> type Real is new Interfaces.IEEE_Float_64; >>> type Length is new Real; >>> >>> package Positions is new Gen.Vectors (3, Length); >>> package Directions is new Gen.Vectors (3, Real); >>> >>> subtype Position is Positions.Vector; >>> subtype Direction is Directions.Vector; >>> >>> function "*" (l: Direction; r: Length) return Position; >>> end Basic; >>> >>> Now my attempt to define this function: >>> >>> function "*" (l: Direction; r: Length) return Position is >>> begin return Positions."*"(Position(l), r); end "*"; >>> >>> gets me the error message in the subject line. >>> >>> Do I have to convert the vector element by element in a loop or is there >>> a more elegant way? >> >> The conversion is rejected because of the conversion condition in RM 4.6 >> (24.5/2): "The component subtypes shall statically match". The component >> (sub)types are Real and Length, which are different types, although >> Length is derived from Real. If you change the declaration of Length >> to be >> >> subtype Length is Real; >> >> the conversion becomes legal. >> > > Thanks a lot for the hint! > Well, I was a little too fast with my response. It works, but it is not what I need. I use type Real for physical dimensionless quantities and Length for lengths. They must be incompatible, you cannot add them. So I came up with a new version of my function: function "*" (l: Direction; r: Length) return Position is begin return Positions."*" (Position'(Length(l(1)), Length(l(2)), Length(l(3))), r); end "*"; (Thanks God I am working with classical physics and not string theory with its 26 dimensions.) -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 13:22 ` hreba @ 2015-07-22 17:50 ` Niklas Holsti 2015-07-22 19:02 ` Dmitry A. Kazakov 0 siblings, 1 reply; 14+ messages in thread From: Niklas Holsti @ 2015-07-22 17:50 UTC (permalink / raw) On 15-07-22 16:22 , hreba wrote: > On 07/22/2015 10:00 AM, hreba wrote: >> On 07/22/2015 02:20 AM, Niklas Holsti wrote: >>> On 15-07-22 04:19 , hreba wrote: >>>> I have a generic vector package: >>>> >>>> generic >>>> dim: positive; >>>> type Real is digits <>; >>>> package Vectors is >>>> type Vector is array (1..dim) of Real; >>>> function "*" (a: Vector; b: Real) return Vector; >>>> end Vectors; >>>> >>>> In another package I want to model the definition of a (physical) >>>> position vector by its direction and module: >>>> >>>> package Basic is >>>> type Real is new Interfaces.IEEE_Float_64; >>>> type Length is new Real; >>>> >>>> package Positions is new Gen.Vectors (3, Length); >>>> package Directions is new Gen.Vectors (3, Real); >>>> >>>> subtype Position is Positions.Vector; >>>> subtype Direction is Directions.Vector; >>>> >>>> function "*" (l: Direction; r: Length) return Position; >>>> end Basic; >>>> >>>> Now my attempt to define this function: >>>> >>>> function "*" (l: Direction; r: Length) return Position is >>>> begin return Positions."*"(Position(l), r); end "*"; >>>> >>>> gets me the error message in the subject line. >>>> >>>> Do I have to convert the vector element by element in a loop or is >>>> there >>>> a more elegant way? >>> >>> The conversion is rejected because of the conversion condition in RM 4.6 >>> (24.5/2): "The component subtypes shall statically match". The component >>> (sub)types are Real and Length, which are different types, although >>> Length is derived from Real. If you change the declaration of Length >>> to be >>> >>> subtype Length is Real; >>> >>> the conversion becomes legal. >>> >> >> Thanks a lot for the hint! >> > Well, I was a little too fast with my response. It works, but it is not > what I need. I use type Real for physical dimensionless quantities and > Length for lengths. They must be incompatible, you cannot add them. For physical units/dimensions, I believe the best current solution is the "aspects" approach in GNAT; see, for example: https://gcc.gnu.org/onlinedocs/gnat_ugn/Performing-Dimensionality-Analysis-in-GNAT.html http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf It is still GNAT-specific, though. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 17:50 ` Niklas Holsti @ 2015-07-22 19:02 ` Dmitry A. Kazakov 0 siblings, 0 replies; 14+ messages in thread From: Dmitry A. Kazakov @ 2015-07-22 19:02 UTC (permalink / raw) On Wed, 22 Jul 2015 20:50:25 +0300, Niklas Holsti wrote: > For physical units/dimensions, I believe the best current solution is > the "aspects" approach in GNAT; see, for example: > > https://gcc.gnu.org/onlinedocs/gnat_ugn/Performing-Dimensionality-Analysis-in-GNAT.html > > http://www.christ-usch-grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf > > It is still GNAT-specific, though. For not GNAT-specific approach, especially, for engineering rather than computations, see: http://www.dmitry-kazakov.de/ada/units.htm -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 1:19 Incompatible types for array conversion hreba 2015-07-22 5:20 ` Niklas Holsti @ 2015-07-22 6:49 ` Georg Bauhaus 2015-07-22 12:57 ` hreba 2015-07-23 13:21 ` hreba 2 siblings, 1 reply; 14+ messages in thread From: Georg Bauhaus @ 2015-07-22 6:49 UTC (permalink / raw) On 22.07.15 03:19, hreba wrote: > I have a generic vector package: > > generic > dim: positive; > type Real is digits <>; > package Vectors is > type Vector is array (1..dim) of Real; > function "*" (a: Vector; b: Real) return Vector; > end Vectors; > > In another package I want to model the definition of a (physical) position vector by its direction and module: > > (...) > Now my attempt to define this function: > > function "*" (l: Direction; r: Length) return Position is > begin return Positions."*"(Position(l), r); end "*"; > > gets me the error message in the subject line. > > Do I have to convert the vector element by element in a loop or is there a more elegant way? There are ways to have the implementation perform exactly the operations needed to produce the result that is needed. Nothing inelegant in that; on the contrary, I find the attempt to convert a Direction into a Position rather disturbing! That's exactly turning the accidental relationship due to assumed similarity of component types into a relationship of Direction and Position that does not exist in the physical world. Type error ;-) caused by assumptions about the implementation dictating specification. In this sense, I'd say that Niklas' suggestion, while technically working, would be papering over a conceptual mistake. (Well, that is what elegance is about, isn't it?) Vectors."*" announces to multiply a Vector of Reals by a Real, returning a Vector of Reals, not converting anything on the way. Maybe the word "Real" still sounds generic, but the instance types aren't. Maybe rethink the solution. I think it could be made adequately flexible, by, for example, considering Position as a vector of discrete numbers in city block space and Direction having one of four possible values only, in that city block space. Then, devise the operations needed. Go back to Position and Direction in a more Euclidean space, allocating a good choice of digits and ranges to each of the types. In your solution, "new Real" is creating a new and different type. This is a good choice when representing things that really are different and should be kept apart easily, with help from the compiler. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 6:49 ` Georg Bauhaus @ 2015-07-22 12:57 ` hreba 2015-07-22 14:22 ` G.B. 0 siblings, 1 reply; 14+ messages in thread From: hreba @ 2015-07-22 12:57 UTC (permalink / raw) On 07/22/2015 03:49 AM, Georg Bauhaus wrote: > On 22.07.15 03:19, hreba wrote: >> I have a generic vector package: >> >> generic >> dim: positive; >> type Real is digits <>; >> package Vectors is >> type Vector is array (1..dim) of Real; >> function "*" (a: Vector; b: Real) return Vector; >> end Vectors; >> >> In another package I want to model the definition of a (physical) >> position vector by its direction and module: >> >> (...) >> Now my attempt to define this function: >> >> function "*" (l: Direction; r: Length) return Position is >> begin return Positions."*"(Position(l), r); end "*"; >> >> gets me the error message in the subject line. >> >> Do I have to convert the vector element by element in a loop or is >> there a more elegant way? > > There are ways to have the implementation perform exactly > the operations needed to produce the result that is needed. > Nothing inelegant in that; on the contrary, I find the > attempt to convert a Direction into a Position rather disturbing! > > That's exactly turning the accidental relationship due to > assumed similarity of component types into a relationship > of Direction and Position that does not exist in the physical world. > Type error ;-) caused by assumptions about the implementation > dictating specification. Wrong. It is common in physics to multiply a dimensionless direction vector (typically a unit vector) with a scalar of some dimension (length, velocity, whatever). The result is a vector with this dimension. > Vectors."*" announces to multiply a Vector of Reals by a Real, > returning a Vector of Reals, not converting anything on the way. > Maybe the word "Real" still sounds generic, but the instance > types aren't. This is an intensional separation of abstraction levels. Package vectors describes mathematical vectors (i.e. elements of a vector space, not just sequences of numbers). Units (e.g. meters) come into play only in clients of this package as in "Basic". > > Maybe rethink the solution. I think it could be made adequately > flexible, by, for example, considering Position as a vector of discrete > numbers in city block space and Direction having one of four possible > values only, in that city block space. Then, devise the operations > needed. Go back to Position and Direction in a more Euclidean > space, allocating a good choice of digits and ranges to each > of the types. > I declared vectors of real types because I need to describe real mathematical numbers (classical continuous physical quantities). There might be a reason to rethink the solution in future, but in a way different to your suggestion: my current implementation allows multiplication of a Position variable with a Length variable resulting in a Position vector. The physically correct dimension would be length squared instead of length. Up to now I can live without that. -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 12:57 ` hreba @ 2015-07-22 14:22 ` G.B. 0 siblings, 0 replies; 14+ messages in thread From: G.B. @ 2015-07-22 14:22 UTC (permalink / raw) On 22.07.15 14:57, hreba wrote: >> That's exactly turning the accidental relationship due to >> assumed similarity of component types into a relationship >> of Direction and Position that does not exist in the physical world. >> Type error ;-) caused by assumptions about the implementation >> dictating specification. > > Wrong. It is common in physics to multiply a dimensionless direction > vector (typically a unit vector) with a scalar of some dimension > (length, velocity, whatever). OK, naming issue then. If the Position can be interpreted as a Point determining a direction, that's an excuse for scalar multiplication with subtype constraints, at the level of implementation, or some conversions. A comment would reduce condescension and unforeseen misunderstanding by non-peers. (If that's wanted.) Proper types and maybe operations would look cleaner to me. > I declared vectors of real types because I need to describe real > mathematical numbers (classical continuous physical quantities). There > might be a reason to rethink the solution in future, but in a way > different to your suggestion: my current implementation allows > multiplication of a Position variable with a Length variable resulting > in a Position vector. The physically correct dimension would be length > squared instead of length. Up to now I can live without that. That's one reason to toss assumptions: if it is not just a scalar multiplication (respecting units), and you don't use SI aspects, another type can do. There are packages for this, I believe Christoph Grein has some online. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Incompatible types for array conversion 2015-07-22 1:19 Incompatible types for array conversion hreba 2015-07-22 5:20 ` Niklas Holsti 2015-07-22 6:49 ` Georg Bauhaus @ 2015-07-23 13:21 ` hreba 2 siblings, 0 replies; 14+ messages in thread From: hreba @ 2015-07-23 13:21 UTC (permalink / raw) I am responding to my own post in order to address all of you. Thanks for your answers, I have learned from them. My actual project has very few units, so I am happy with my simple solution. For any future case with more units I will for sure follow your links. -- Frank Hrebabetzky +55 / 48 / 3235 1106 Florianopolis, Brazil ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-07-27 23:12 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-22 1:19 Incompatible types for array conversion hreba 2015-07-22 5:20 ` Niklas Holsti 2015-07-22 7:13 ` Simon Wright 2015-07-22 7:41 ` Niklas Holsti 2015-07-22 12:32 ` Simon Wright 2015-07-27 23:12 ` Randy Brukardt 2015-07-22 13:00 ` hreba 2015-07-22 13:22 ` hreba 2015-07-22 17:50 ` Niklas Holsti 2015-07-22 19:02 ` Dmitry A. Kazakov 2015-07-22 6:49 ` Georg Bauhaus 2015-07-22 12:57 ` hreba 2015-07-22 14:22 ` G.B. 2015-07-23 13:21 ` hreba
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox