* When is a rename not a rename?
@ 2013-01-29 1:24 Adam Beneschan
2013-01-30 0:28 ` Randy Brukardt
2013-02-01 10:44 ` Ada novice
0 siblings, 2 replies; 19+ messages in thread
From: Adam Beneschan @ 2013-01-29 1:24 UTC (permalink / raw)
I've always assumed that if you declare a name to be a rename of some other entity (*), there wouldn't be any impact on the program, other than that you can use the new name to mean the same thing as the thing that it renames.
In particular, for library unit packages, if P2 is a library unit package that renames P1, then a unit that says "with P2;" should work the same as one that says "with P1;" after you've done whatever is necessary to make sure all names in the unit refer to the same entities. Right?
I've just discovered that this isn't the case...
with P1;
with P3;
package P2 renames P1;
Now, a program that says "with P2;" may operate differently from one that with's P1--because saying "with P2" will cause P3's elaboration code to be executed at the beginning of the program, while saying "with P1" will not [unless P3 is included in the program via some other path].
I wonder if this was the intent, or if it's a "bug" in the language definition?
-- Adam
(*) Not counting a renaming-as-body, which is different because the first declaration of the name is *not* a renaming declaration.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-01-29 1:24 When is a rename not a rename? Adam Beneschan
@ 2013-01-30 0:28 ` Randy Brukardt
2013-01-30 0:52 ` Adam Beneschan
2013-02-01 10:44 ` Ada novice
1 sibling, 1 reply; 19+ messages in thread
From: Randy Brukardt @ 2013-01-30 0:28 UTC (permalink / raw)
What else could it mean? We don't want to be ignoring "with" clauses in one
rarely used case, so it has to cause a semantic dependence here.
And this doesn't have anything to do with the rename per-se; this is a
compilation unit like any other (that happens to be a rename), and it is the
compilation unit that has this effect, not the rename. I always think of all
compilation units as packages (imagining an invisible package wrapping
anything that isn't a normal package), and when you do that, this makes
plenty of sense.
Randy.
"Adam Beneschan" <adam@irvine.com> wrote in message
news:6d66d1c4-ed22-446b-a9d7-dc806ae1ef8f@googlegroups.com...
I've always assumed that if you declare a name to be a rename of some other
entity (*), there wouldn't be any impact on the program, other than that you
can use the new name to mean the same thing as the thing that it renames.
In particular, for library unit packages, if P2 is a library unit package
that renames P1, then a unit that says "with P2;" should work the same as
one that says "with P1;" after you've done whatever is necessary to make
sure all names in the unit refer to the same entities. Right?
I've just discovered that this isn't the case...
with P1;
with P3;
package P2 renames P1;
Now, a program that says "with P2;" may operate differently from one that
with's P1--because saying "with P2" will cause P3's elaboration code to be
executed at the beginning of the program, while saying "with P1" will not
[unless P3 is included in the program via some other path].
I wonder if this was the intent, or if it's a "bug" in the language
definition?
-- Adam
(*) Not counting a renaming-as-body, which is different because the first
declaration of the name is *not* a renaming declaration.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-01-30 0:28 ` Randy Brukardt
@ 2013-01-30 0:52 ` Adam Beneschan
2013-01-30 9:31 ` Dmitry A. Kazakov
0 siblings, 1 reply; 19+ messages in thread
From: Adam Beneschan @ 2013-01-30 0:52 UTC (permalink / raw)
On Tuesday, January 29, 2013 4:28:29 PM UTC-8, Randy Brukardt wrote:
> What else could it mean? We don't want to be ignoring "with" clauses in one
> rarely used case, so it has to cause a semantic dependence here.
>
> And this doesn't have anything to do with the rename per-se; this is a
> compilation unit like any other (that happens to be a rename), and it is the
> compilation unit that has this effect, not the rename. I always think of all
> compilation units as packages (imagining an invisible package wrapping
> anything that isn't a normal package), and when you do that, this makes
> plenty of sense.
Yes... it just requires me to change my thinking a little bit about what a "rename" means. I thought it set up a synonym, but in the case of a library-level rename it isn't quite true; thinking about it as a wrapper makes more sense. It's just a bit surprising, and I was curious whether this was something that was considered when the semantics were defined in Ada 95.
And no, I wouldn't have wanted "with" clauses to be ignored, but the language could have made "with" clauses on library-level renames illegal except for "with" clauses that denoted the renamed unit or an ancestor or a unit on which the renamed unit's specification depends semantically, or something along those lines. Not that I'm proposing any such change now.
-- Adam
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-01-30 0:52 ` Adam Beneschan
@ 2013-01-30 9:31 ` Dmitry A. Kazakov
2013-01-30 14:35 ` ytomino
0 siblings, 1 reply; 19+ messages in thread
From: Dmitry A. Kazakov @ 2013-01-30 9:31 UTC (permalink / raw)
On Tue, 29 Jan 2013 16:52:03 -0800 (PST), Adam Beneschan wrote:
> Yes... it just requires me to change my thinking a little bit about what a
> "rename" means.
I wished the rule that a renaming shall never conflict with the thing is
renames [and never creates logically new objects].
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-01-30 9:31 ` Dmitry A. Kazakov
@ 2013-01-30 14:35 ` ytomino
0 siblings, 0 replies; 19+ messages in thread
From: ytomino @ 2013-01-30 14:35 UTC (permalink / raw)
Cc: mailbox
2013年1月30日水曜日 18時31分21秒 UTC+9 Dmitry A. Kazakov:
> I wished the rule that a renaming shall never conflict with the thing is
> renames [and never creates logically new objects].
with XXX;
package YYY is
subype T is XXX.T;
function "=" (Left, Right : T) return Boolean renames XXX."=";
end YYY;
...
declare
use YYY; -- introduce YYY."="
use type YYY.T; -- introduce XXX."="
A, B : T;
begin
if A = B then -- error because two "=" are conflicted!
...
I wish this case may be not conflicted.
There is probably no way to create a package having any entities perfectly rename something in another package.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-01-29 1:24 When is a rename not a rename? Adam Beneschan
2013-01-30 0:28 ` Randy Brukardt
@ 2013-02-01 10:44 ` Ada novice
2013-02-01 11:27 ` Dmitry A. Kazakov
1 sibling, 1 reply; 19+ messages in thread
From: Ada novice @ 2013-02-01 10:44 UTC (permalink / raw)
On Tuesday, January 29, 2013 2:24:55 AM UTC+1, Adam Beneschan wrote:
> I've always assumed that if you declare a name to be a rename of some other entity (*), there wouldn't be any impact on the program, other than that you can use the new name to mean the same thing as the thing that it renames.
Very interesting discussion and I am "perplexed" if what you say is not true. If you have a minimal example that is proving the contrary, please post it here.
Thanks.
YC
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 10:44 ` Ada novice
@ 2013-02-01 11:27 ` Dmitry A. Kazakov
2013-02-01 17:32 ` Adam Beneschan
2013-02-01 17:48 ` Ada novice
0 siblings, 2 replies; 19+ messages in thread
From: Dmitry A. Kazakov @ 2013-02-01 11:27 UTC (permalink / raw)
On Fri, 1 Feb 2013 02:44:21 -0800 (PST), Ada novice wrote:
> If you have a minimal example that is proving the contrary, please post it here.
Here is how renaming is not renaming:
with Ada.IO_Exceptions;
procedure Test is
package P is
End_Error : exception renames Ada.IO_Exceptions.End_Error;
end P;
use P, Ada.IO_Exceptions;
begin
null;
exception
when End_Error => -- Compile error, should be none
null;
end Test;
This is "diamond diagram" constructed using renaming:
procedure Test is
package P is
I : Integer;
end P;
package Q is
J : Integer renames P.I;
end Q;
package R is
J : Integer renames P.I;
end R;
use Q, R;
X : Integer := J; -- Compile error, should be none
begin
null;
end Test;
[Diamond diagram is common-place bogus argument against MI]
Yet another example when rename is something totally broken:
with Ada.Text_IO; use Ada.Text_IO;
procedure Test is
X : Integer;
Y : Positive renames X;
begin
Y := -1;
Put_Line ("And today positive number is " & Integer'Image (Y));
end Test;
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 11:27 ` Dmitry A. Kazakov
@ 2013-02-01 17:32 ` Adam Beneschan
2013-02-01 18:31 ` ytomino
` (2 more replies)
2013-02-01 17:48 ` Ada novice
1 sibling, 3 replies; 19+ messages in thread
From: Adam Beneschan @ 2013-02-01 17:32 UTC (permalink / raw)
On Friday, February 1, 2013 3:27:02 AM UTC-8, Dmitry A. Kazakov wrote:
> On Fri, 1 Feb 2013 02:44:21 -0800 (PST), Ada novice wrote:
>
> > If you have a minimal example that is proving the contrary, please post it here.
>
> Here is how renaming is not renaming:
These examples aren't close to what I was getting at. I was trying to talk about cases where Y renames X; but if you replace X in your program with Y, and both programs are legal, the program runs differently. (Not counting cases where changing X to Y causes changes in the meanings of other identifiers later in the program because of the visibility rules.)
Your first two examples are cases where you can't use a rename because of the language rules, so these are definitely not the same thing. In the first case, you just don't like how the scoping rules apply to exception handlers--it has nothing to do with renaming. The second case is one that probably could be fixed by language rules, although I doubt it will happen. It's mildly annoying that an ambiguous identifier error can be triggered by two identifiers with the same name that rename the same entity. The third case is the opposite of what I'm talking about: if you replace X := -1 with Y := -1 the program has the exact same behavior. It may be annoying that the rename allows you to put an additional constraint on the renaming variable and then ignores it. I agree that it may have been a mistake to allow this. But it's still not the same thing I was discussing.
Here's an example that may answer YC's question:
package Pack1 is
pragma Elaborate_Body;
end Pack1;
with Ada.Text_IO;
package body Pack1 is
begin
Text_IO.Put_Line ("Pack1 is elaborated");
end Pack1;
package Pack2 is
end Pack2;
with Pack1, Pack2;
package Pack3 renames Pack2;
with Pack2; -- with Pack3; <=== HERE
procedure Test is
begin
null;
end Test;
If you run Test, nothing happens; but if you change the HERE line to "with Pack3;", then when you run Test, it outputs "Pack1 is elaborated", even though Pack3 renames Pack2. That's what I was talking about. Pack3 is not a strict "rename" in the sense that I understand the term (and apparently Randy likes to think of it as a wrapper of sorts rather than a strict rename).
Another possible example is when a subprogram renames another one but changes a default parameter:
procedure P1 (N1 : Integer; N2 : Integer := 0) is ...
procedure P2 (N1 : Integer; N2 : Integer := 1) renames P1;
P1(5);
P2(5);
Another case where P2 renames P1, but changing P1 to P2 has a different effect. I think this capability was allowed deliberately, though, with the expectation that it might be useful. Probably, if you do something like this, you should put comments on P2 to make it clear that this isn't a strict rename---and similarly on Pack3 in my earlier example.
-- Adam
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 17:32 ` Adam Beneschan
@ 2013-02-01 18:31 ` ytomino
2013-02-02 1:40 ` Adam Beneschan
2013-02-02 0:42 ` Brian Drummond
2013-02-05 9:53 ` Ada novice
2 siblings, 1 reply; 19+ messages in thread
From: ytomino @ 2013-02-01 18:31 UTC (permalink / raw)
How is my previous post?
First,
package XXX is
type T is private;
function "=" (Left, Right : T) return Boolean;
end XXX;
declare
use XXX;
use type T;
A, B : T;
begin
if A = B then -- legal
Then, ready new package YYY renaming XXX.
with XXX;
package YYY is
subtype T is XXX.T;
function "=" (Left, Right : T) return Boolean renames XXX."=";
end YYY;
And, replace.
declare
use YYY; -- change here
use type T;
A, B : T;
begin
if A = B then -- error !!
I want to split an existing package into some implementation files and one interface file that renames all declarations in each implementation file.
For example, from
package Large is
type T1 is private;
procedure Proc1 (Obj : T1);
type T1_Supplement is private;
procedure Proc2 (Obj : T1; Arg : T1_Supplement);
...
type T2;
...
end Large;
to
with Small1, Small2;
package Large is
subtype T1 is Small1.T1;
procedure Proc1 (Obj : T1) renames Small1.Proc1;
subtype T1_Supplement is Small1.T1_Supplement;
procedure Primitive (Obj : T1; Arg : T1_Supplement) renamens Small1.Proc2;
... renames all entities from Small1 ...
subtype T2 is Small2.T2;
... renames all entities from Small2 ...
end Large;
But, "use type" causes above confliction.
("type T1 is new Small1.T1;" resolves for only T1, but T1_Supplement should be renamed still.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 18:31 ` ytomino
@ 2013-02-02 1:40 ` Adam Beneschan
2013-02-02 12:24 ` ytomino
2013-02-02 14:26 ` Robert A Duff
0 siblings, 2 replies; 19+ messages in thread
From: Adam Beneschan @ 2013-02-02 1:40 UTC (permalink / raw)
On Friday, February 1, 2013 10:31:06 AM UTC-8, ytomino wrote:
> How is my previous post?
>
> First,
>
> package XXX is
> type T is private;
> function "=" (Left, Right : T) return Boolean;
> end XXX;
>
> declare
> use XXX;
> use type T;
> A, B : T;
> begin
> if A = B then -- legal
>
> Then, ready new package YYY renaming XXX.
>
> with XXX;
> package YYY is
> subtype T is XXX.T;
> function "=" (Left, Right : T) return Boolean renames XXX."=";
> end YYY;
>
> And, replace.
>
> declare
> use YYY; -- change here
> use type T;
> A, B : T;
> begin
> if A = B then -- error !!
I can understand why this would be annoying. It seems like a problem. I don't know if it's enough of a problem to consider fixing the language. It wouldn't be trivial. Perhaps 8.6(30) could be modified to add some concept of two acceptable interpretations that are essentially the same because the usage names end up denoting the same entity via renaming. It seems hard to get the wording right. Plus you have to deal with things like this:
package XXX is
type T is private;
procedure Operation (Obj : in out T; Offset : Integer := 0);
end XXX;
package YYY is
subtype T renames XXX.T;
procedure Operation (Obj : in out T; Offset : Integer := -1)
renames XXX.Operation;
end YYY;
...
use YYY;
use type T;
Z : T;
Operation(Z);
Although the two Operation's that could be denoted by this actually refer to the same declaration after renaming is considered, it's still ambiguous since we don't know what should be passed for Offset. Parameter names can also be different in a subprogram rename, which can pose another problem. The language rules would have to be written to allow the case you're interested in but disallow examples like mine. Not easy.
-- Adam
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-02 1:40 ` Adam Beneschan
@ 2013-02-02 12:24 ` ytomino
2013-02-02 14:26 ` Robert A Duff
1 sibling, 0 replies; 19+ messages in thread
From: ytomino @ 2013-02-02 12:24 UTC (permalink / raw)
On Saturday, February 2, 2013 10:40:40 AM UTC+9, Adam Beneschan wrote:
> Although the two Operation's that could be denoted by this actually refer to the same declaration after renaming is considered, it's still ambiguous since we don't know what should be passed for Offset. Parameter names can also be different in a subprogram rename, which can pose another problem. The language rules would have to be written to allow the case you're interested in but disallow examples like mine. Not easy.
Right you are. I'm afraid for/have to be careful not to make typo in renaming.
I think... in the case, human have not to write "renames" by hand. Actually, There are some typo in examples (including mine...orz) presented in this thread. :-)
"Integrated" nested packages proposed in AI05-0135 seems easy and good to me.
with XXX;
package YYY is
use package <Included_XXX> renames XXX;
end YYY;
with Small1, Small2;
package Large is
use package <Included_Small_1> renames Small1;
use package <Included_Small_2> renames Small2;
end Large;
Perhaps, it too makes large headers like Win32Ada more simpler.
As another solution, I have to remove "use type" from client code because "use" implies "use type". But I have to remove "use type" from other person's code...
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-02 1:40 ` Adam Beneschan
2013-02-02 12:24 ` ytomino
@ 2013-02-02 14:26 ` Robert A Duff
2013-02-02 17:11 ` Shark8
1 sibling, 1 reply; 19+ messages in thread
From: Robert A Duff @ 2013-02-02 14:26 UTC (permalink / raw)
Adam Beneschan <adam@irvine.com> writes:
> I can understand why this would be annoying. It seems like a problem.
> I don't know if it's enough of a problem to consider fixing the
> language. It wouldn't be trivial.
Nothing related to visibility is trivial, but I think it could be
done, and would be an improvement to the language. See 8.3(12.3),
where something similar is going on.
On the other hand, compiler writers aren't going to want to mess around
with this part of their compiler.
A similar example: Suppose we have:
X : constant T := Some_Package.X;
And suppose both X's are potentially use-visible at some
place. You might want to be able to refer to X. (Currently,
the X's hide each other, and I doubt that's going to change.)
- Bob
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-02 14:26 ` Robert A Duff
@ 2013-02-02 17:11 ` Shark8
0 siblings, 0 replies; 19+ messages in thread
From: Shark8 @ 2013-02-02 17:11 UTC (permalink / raw)
On Saturday, February 2, 2013 8:26:01 AM UTC-6, Robert A Duff wrote:
>
> A similar example: Suppose we have:
>
> X : constant T := Some_Package.X;
>
> And suppose both X's are potentially use-visible at some
> place. You might want to be able to refer to X. (Currently,
> the X's hide each other, and I doubt that's going to change.)
Shouldn't the compiler complain of ambiguity and force a fully-qualified referral in that case? (Though you could 'promote' one's visibility to 'default' via renames in the current compilation-unit's context.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 17:32 ` Adam Beneschan
2013-02-01 18:31 ` ytomino
@ 2013-02-02 0:42 ` Brian Drummond
2013-02-02 11:43 ` AdaMagica
2013-02-05 9:53 ` Ada novice
2 siblings, 1 reply; 19+ messages in thread
From: Brian Drummond @ 2013-02-02 0:42 UTC (permalink / raw)
On Fri, 01 Feb 2013 09:32:42 -0800, Adam Beneschan wrote:
> On Friday, February 1, 2013 3:27:02 AM UTC-8, Dmitry A. Kazakov wrote:
>> On Fri, 1 Feb 2013 02:44:21 -0800 (PST), Ada novice wrote:
>>
>> > If you have a minimal example that is proving the contrary, please
>> > post it here.
>>
>> Here is how renaming is not renaming:
>
> Another possible example is when a subprogram renames another one but
> changes a default parameter:
There was also a recent specimen where a rename made a procedure's
parameter disappear!
The trick was something like renaming an object.method call to just
renamed_method.
I forget the precise details but I recall it was legal; taking its access
was not (though astonishingly, it worked in current Gnat revisions)
- Brian
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-02 0:42 ` Brian Drummond
@ 2013-02-02 11:43 ` AdaMagica
2013-02-03 11:50 ` Brian Drummond
0 siblings, 1 reply; 19+ messages in thread
From: AdaMagica @ 2013-02-02 11:43 UTC (permalink / raw)
On Saturday, February 2, 2013 1:42:29 AM UTC+1, Brian Drummond wrote:
> On Fri, 01 Feb 2013 09:32:42 -0800, Adam Beneschan wrote:
> The trick was something like renaming an object.method call to just
> renamed_method.
>
> I forget the precise details but I recall it was legal; taking its access
> was not (though astonishingly, it worked in current Gnat revisions)
See
http://en.wikibooks.org/wiki/Ada_Programming/Subprograms#Renaming
package Some_Package is
type Message_Type is tagged null record;
procedure Print (Message: in Message_Type);
end Some_Package;
with Some_Package;
procedure Main is
Message: Some_Package.Message_Type;
procedure Print renames Message.Print; -- this has convention intrinsic, see RM 6.3.1(10.1/2)
Method_Ref: access procedure := Print'Access; -- thus taking 'Access should be illegal; GNAT GPL 2012 allows this
begin -- All these calls are equivalent:
Some_Package.Print (Message); -- traditional call without use clause
Message.Print; -- Ada 2005 method.object call - note: no use clause necessary
Print; -- Message.Print is a parameterless procedure and can be renamed as such
Method_Ref.all; -- GNAT GPL 2012 allows illegal call via an access to the renamed procedure Print
-- This has been corrected in the current version (as of Nov 22, 2012)
end Main;
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 17:32 ` Adam Beneschan
2013-02-01 18:31 ` ytomino
2013-02-02 0:42 ` Brian Drummond
@ 2013-02-05 9:53 ` Ada novice
2 siblings, 0 replies; 19+ messages in thread
From: Ada novice @ 2013-02-05 9:53 UTC (permalink / raw)
On Friday, February 1, 2013 6:32:42 PM UTC+1, Adam Beneschan wrote:
> Here's an example that may answer YC's question:
>
> package Pack1 is
>
> pragma Elaborate_Body;
>
> end Pack1;
>
>
>
> with Ada.Text_IO;
>
> package body Pack1 is
>
> begin
>
> Text_IO.Put_Line ("Pack1 is elaborated");
>
> end Pack1;
>
>
>
> package Pack2 is
>
> end Pack2;
>
>
>
> with Pack1, Pack2;
>
> package Pack3 renames Pack2;
>
>
>
> with Pack2; -- with Pack3; <=== HERE
>
> procedure Test is
>
> begin
>
> null;
>
> end Test;
>
>
> Another possible example is when a subprogram renames another one but changes a default parameter:
>
>
>
> procedure P1 (N1 : Integer; N2 : Integer := 0) is ...
>
>
>
> procedure P2 (N1 : Integer; N2 : Integer := 1) renames P1;
>
>
>
> P1(5);
>
> P2(5);
>
Thanks for these two very good examples. I shall be careful with renames from now on.
Thanks
YC
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: When is a rename not a rename?
2013-02-01 11:27 ` Dmitry A. Kazakov
2013-02-01 17:32 ` Adam Beneschan
@ 2013-02-01 17:48 ` Ada novice
1 sibling, 0 replies; 19+ messages in thread
From: Ada novice @ 2013-02-01 17:48 UTC (permalink / raw)
Thanks for the negative "today's positive number" example :).
I see that your examples may be looking at renaming the types of variables except in the 1st example.
If I use rename in a program, it is because I can have a general method of doing something plus some specific cases that require some changes in the general method. So I have e.g.
The file General_Method.ads as
With Specific_Case_A;
Package General_Method renames Specific_Case_A;
--With Specific_Case_B;
--Package General_Method renames Specific_Case_B;
Now I am thinking what I am really doing in my example: should it be package X renames Y or package Y renames X...whatever
YC
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2013-02-05 9:53 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-29 1:24 When is a rename not a rename? Adam Beneschan
2013-01-30 0:28 ` Randy Brukardt
2013-01-30 0:52 ` Adam Beneschan
2013-01-30 9:31 ` Dmitry A. Kazakov
2013-01-30 14:35 ` ytomino
2013-02-01 10:44 ` Ada novice
2013-02-01 11:27 ` Dmitry A. Kazakov
2013-02-01 17:32 ` Adam Beneschan
2013-02-01 18:31 ` ytomino
2013-02-02 1:40 ` Adam Beneschan
2013-02-02 12:24 ` ytomino
2013-02-02 14:26 ` Robert A Duff
2013-02-02 17:11 ` Shark8
2013-02-02 0:42 ` Brian Drummond
2013-02-02 11:43 ` AdaMagica
2013-02-03 11:50 ` Brian Drummond
2013-02-03 12:16 ` AdaMagica
2013-02-05 9:53 ` Ada novice
2013-02-01 17:48 ` Ada novice
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox