* Compilation error (GNAT bug?) @ 2014-05-20 18:32 Victor Porton 2014-05-20 18:43 ` Simon Wright 0 siblings, 1 reply; 13+ messages in thread From: Victor Porton @ 2014-05-20 18:32 UTC (permalink / raw) package My is procedure C_Raptor_New_World with Import => True, Convention => C, External_Name => "raptor_new_world"; end My; $ gnat compile -gnat2012 my.ads gcc-4.6 -c -gnat2012 my.ads my.ads:4:11: aspect identifier expected gnatmake: "my.ads" compilation error Why it does not compile? Is it a GNAT bug? -- Victor Porton - http://portonvictor.org ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Compilation error (GNAT bug?) 2014-05-20 18:32 Compilation error (GNAT bug?) Victor Porton @ 2014-05-20 18:43 ` Simon Wright 2014-05-20 22:22 ` spec/body/rep (Was: Compilation error (GNAT bug?)) Georg Bauhaus 0 siblings, 1 reply; 13+ messages in thread From: Simon Wright @ 2014-05-20 18:43 UTC (permalink / raw) Victor Porton <porton@narod.ru> writes: > package My is > > procedure C_Raptor_New_World > with Import => True, Convention => C, External_Name => "raptor_new_world"; > > end My; > > $ gnat compile -gnat2012 my.ads > gcc-4.6 -c -gnat2012 my.ads > my.ads:4:11: aspect identifier expected > gnatmake: "my.ads" compilation error > > Why it does not compile? Is it a GNAT bug? No, just an old version of GNAT. GCC 4.7 fails too; 4.8 is OK. GNAT GPL 2011 fails; 2012 is OK. ^ permalink raw reply [flat|nested] 13+ messages in thread
* spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-20 18:43 ` Simon Wright @ 2014-05-20 22:22 ` Georg Bauhaus 2014-05-23 21:21 ` Randy Brukardt 0 siblings, 1 reply; 13+ messages in thread From: Georg Bauhaus @ 2014-05-20 22:22 UTC (permalink / raw) On 20/05/14 20:43, Simon Wright wrote: > Victor Porton <porton@narod.ru> writes: > >> package My is >> >> procedure C_Raptor_New_World >> with Import => True, Convention => C, External_Name => "raptor_new_world"; >> >> end My; >> >> $ gnat compile -gnat2012 my.ads >> gcc-4.6 -c -gnat2012 my.ads >> my.ads:4:11: aspect identifier expected >> gnatmake: "my.ads" compilation error >> >> Why it does not compile? Is it a GNAT bug? > > No, just an old version of GNAT. GCC 4.7 fails too; 4.8 is OK. GNAT GPL > 2011 fails; 2012 is OK. procedure Foo (Arg : in out T) with Global => ... Pre => ... Post => ... Convention => ... External_Name => ... Linker_Options => ... Inline; Some aspects, such as Linker_Options, are about things outside the program. A Convention identifier less so, it addresses any client of package My and insofar belongs in the public part with the declaration. Then there are aspects of still other kinds, such as Pre/Post conditions of contracts. They cannot very well exist without their declarative item, just like pragmatic aspect Inline, although the latter may written separately. The pin board style list of aspects just lumps all of these different kinds together after "with". What if the "external aspects" went elsewhere? For example, in a representation unit. (That's a name I remember). With rep units, the source text proper becomes more portable, and more configurable at the same time. There is no need to change aspects in the source text when switching environments or when changing the configuration (Linker_Options is one example). Just pick a suitable rep unit. Declarations also become more readable, insofar as they'd focus on just the logic, not link names and such. Representation units can provide an Ada version of dependency injection, even when injection happens at compile time. In fact, GNAT already supports "outsourcing" certain aspects with the help of project files. Do some of the other compilers do that, too? Since aspects are a fairly new addition to the language, chances are that representation units will not generate backwards compatibility issues. Would representation units help producing clear separation of concerns? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-20 22:22 ` spec/body/rep (Was: Compilation error (GNAT bug?)) Georg Bauhaus @ 2014-05-23 21:21 ` Randy Brukardt 2014-05-27 5:16 ` J-P. Rosen 0 siblings, 1 reply; 13+ messages in thread From: Randy Brukardt @ 2014-05-23 21:21 UTC (permalink / raw) "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message news:537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net... > On 20/05/14 20:43, Simon Wright wrote: >> Victor Porton <porton@narod.ru> writes: >> >>> package My is >>> >>> procedure C_Raptor_New_World >>> with Import => True, Convention => C, External_Name => >>> "raptor_new_world"; >>> >>> end My; >>> >>> $ gnat compile -gnat2012 my.ads >>> gcc-4.6 -c -gnat2012 my.ads >>> my.ads:4:11: aspect identifier expected >>> gnatmake: "my.ads" compilation error >>> >>> Why it does not compile? Is it a GNAT bug? >> >> No, just an old version of GNAT. GCC 4.7 fails too; 4.8 is OK. GNAT GPL >> 2011 fails; 2012 is OK. > > procedure Foo (Arg : in out T) > with > Global => ... > Pre => ... > Post => ... > Convention => ... > External_Name => ... > Linker_Options => ... > Inline; > > Some aspects, such as Linker_Options, are about things outside the > program. Linker_Options is not an aspect. Aspects apply to specific entities; one uses pragmas to specify things that apply to the entire partition. ("Configuration pragmas"). > A Convention identifier less so, it addresses any client of > package My and insofar belongs in the public part with the declaration. > Then there are aspects of still other kinds, such as Pre/Post conditions > of contracts. They cannot very well exist without their declarative item, > just like pragmatic aspect Inline, although the latter may written > separately. > > The pin board style list of aspects just lumps all of these different > kinds together after "with". > > What if the "external aspects" went elsewhere? For example, in a > representation unit. (That's a name I remember). With rep units, > the source text proper becomes more portable, and more configurable > at the same time. There is no need to change aspects in the source > text when switching environments or when changing the configuration > (Linker_Options is one example). Just pick a suitable rep unit. > Declarations also become more readable, insofar as they'd focus on > just the logic, not link names and such. Huh? A "representation unit" or whatever you call it is part of the "source text". You can't run the program without it. That's the problem with fancy project management (no matter how well-designed) -- it's part of the program (you can't build it without it), but it's outside of the language definition. (And it would be impractical to add it to the language definition.) So it causes vendor lock-in. > Representation units can provide an Ada version of dependency > injection, even when injection happens at compile time. > > In fact, GNAT already supports "outsourcing" certain aspects with the > help of project files. Do some of the other compilers do that, too? > > Since aspects are a fairly new addition to the language, chances > are that representation units will not generate backwards compatibility > issues. > > Would representation units help producing clear separation of concerns? I don't think so, mainly because you already have such a capability: constants! It's not the presence or absence of an aspect that changes, it's the value. So it might make sense to have a package specifically for the target-specific details (many systems do that, including the ACATS). For instance: package Target_Specific is -- Package for Windows. pragma Linker_Options (...); -- Data types: type Largest_Integer is range -2**31 .. 2**31 with Size => 32; type Largest_Modular is mod 2**32 with Size => 32; -- Interfacing details for package Blarch: Foo_External_Name : constant String := "..."; Bar_External_Name : constant String := "..."; ... end Target_Specific; And then have separate versions of the package for the various targets supported. I don't see any benefit to creating a new kind of unit (with the massive costs that would have for compilation systems) just to reproduce capabilities that already exist. (For what's it's worth, I don't believe that it makes sense to separate representation from other aspects (pun intended) of a declaration. All of these things have fundamental impacts on the semantics of an entity, and trying to deny that (as the Ada 83 designers attempted to) just leads to a forest of odd restrictions and complex rules designed to keep a fiction going while still allowing a simple compiler design. [The majority of the freezing rules come about because of this desire, for instance.] And it isn't even a very useful fiction. See type Largest_Integer above; if we need to give that a different size on some other target, we need to change the range, too. That's pretty common when dealing with representation.[Disclaimer: My personal views here may not be held by others, even within the ARG.]) Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-23 21:21 ` Randy Brukardt @ 2014-05-27 5:16 ` J-P. Rosen 2014-05-27 6:22 ` Niklas Holsti 0 siblings, 1 reply; 13+ messages in thread From: J-P. Rosen @ 2014-05-27 5:16 UTC (permalink / raw) Le 23/05/2014 23:21, Randy Brukardt a écrit : > I don't think so, mainly because you already have such a capability: > constants! It's not the presence or absence of an aspect that changes, it's > the value. So it might make sense to have a package specifically for the > target-specific details (many systems do that, including the ACATS). > > For instance: > package Target_Specific is > -- Package for Windows. > pragma Linker_Options (...); > > -- Data types: > type Largest_Integer is range -2**31 .. 2**31 with Size => 32; > type Largest_Modular is mod 2**32 with Size => 32; > > -- Interfacing details for package Blarch: > Foo_External_Name : constant String := "..."; > Bar_External_Name : constant String := "..."; > > ... > end Target_Specific; > > And then have separate versions of the package for the various targets > supported. And to ease porting, have a package called Target_Specific_Windows, another one called Target_Specific_Linux. All the users do: with Target_Specific; and have the following library-lever renaming: with Target_Specific_Windows; package Target_Specific renames Target_Specific_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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 5:16 ` J-P. Rosen @ 2014-05-27 6:22 ` Niklas Holsti 2014-05-27 8:54 ` J-P. Rosen 2014-05-27 8:55 ` Dmitry A. Kazakov 0 siblings, 2 replies; 13+ messages in thread From: Niklas Holsti @ 2014-05-27 6:22 UTC (permalink / raw) On 14-05-27 08:16 , J-P. Rosen wrote: > Le 23/05/2014 23:21, Randy Brukardt a écrit : >> I don't think so, mainly because you already have such a capability: >> constants! It's not the presence or absence of an aspect that changes, it's >> the value. So it might make sense to have a package specifically for the >> target-specific details (many systems do that, including the ACATS). >> >> For instance: >> package Target_Specific is >> -- Package for Windows. >> pragma Linker_Options (...); >> >> -- Data types: >> type Largest_Integer is range -2**31 .. 2**31 with Size => 32; >> type Largest_Modular is mod 2**32 with Size => 32; >> >> -- Interfacing details for package Blarch: >> Foo_External_Name : constant String := "..."; >> Bar_External_Name : constant String := "..."; >> >> ... >> end Target_Specific; >> >> And then have separate versions of the package for the various targets >> supported. > And to ease porting, have a package called Target_Specific_Windows, > another one called Target_Specific_Linux. All the users do: > with Target_Specific; > > and have the following library-lever renaming: > with Target_Specific_Windows; > package Target_Specific renames Target_Specific_Windows; I don't see what advantage such as a library-level renaming gives. If one is developing for several platforms, say Windows and Linux, there will then be two library-level renamings somewhere, one as above and the other using Target_Specific_Linux, but some compiler-specific way is still needed to choose which of the library level renamings to include in the compilation. So one could just as well call both the target-specific packages Target_Specific, directly, and use the same compiler-specific way to choose which one to compile. For example, I use GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows") which contains the version of Target_Specific to be compiled. Would there be some sense in being able to specify such library-level renamings as configuration pragmas? This might give us a standard way to choose component versions depending on the configuration (leaving as compiler-specific the way to select which configuration is to be compiled... :-) -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 6:22 ` Niklas Holsti @ 2014-05-27 8:54 ` J-P. Rosen 2014-05-27 8:55 ` Dmitry A. Kazakov 1 sibling, 0 replies; 13+ messages in thread From: J-P. Rosen @ 2014-05-27 8:54 UTC (permalink / raw) Le 27/05/2014 08:22, Niklas Holsti a écrit : >> And to ease porting, have a package called Target_Specific_Windows, >> > another one called Target_Specific_Linux. All the users do: >> > with Target_Specific; >> > >> > and have the following library-lever renaming: >> > with Target_Specific_Windows; >> > package Target_Specific renames Target_Specific_Windows; > I don't see what advantage such as a library-level renaming gives. If > one is developing for several platforms, say Windows and Linux, there > will then be two library-level renamings somewhere, one as above and the > other using Target_Specific_Linux, but some compiler-specific way is > still needed to choose which of the library level renamings to include > in the compilation. So one could just as well call both the > target-specific packages Target_Specific, directly, and use the same > compiler-specific way to choose which one to compile. For example, I use > GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows") > which contains the version of Target_Specific to be compiled. The way I do it, both renamings are in the same file, one of them commented out. I just comment/uncomment the right one at the time of build. Not fully automated, but easy, and I argue (with the C people) that it is hardly more work than changing a global variable in a Makefile. The point is: one single simple change in one file, and your whole application switches OSes. The other benefit being that you see quite well which parameters are for which OS. But of course, it all depends on your build process, use case, and personal taste... -- 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 6:22 ` Niklas Holsti 2014-05-27 8:54 ` J-P. Rosen @ 2014-05-27 8:55 ` Dmitry A. Kazakov 2014-05-27 15:45 ` G.B. 1 sibling, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2014-05-27 8:55 UTC (permalink / raw) On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote: > On 14-05-27 08:16 , J-P. Rosen wrote: >> Le 23/05/2014 23:21, Randy Brukardt a écrit : >>> I don't think so, mainly because you already have such a capability: >>> constants! It's not the presence or absence of an aspect that changes, it's >>> the value. So it might make sense to have a package specifically for the >>> target-specific details (many systems do that, including the ACATS). >>> >>> For instance: >>> package Target_Specific is >>> -- Package for Windows. >>> pragma Linker_Options (...); >>> >>> -- Data types: >>> type Largest_Integer is range -2**31 .. 2**31 with Size => 32; >>> type Largest_Modular is mod 2**32 with Size => 32; >>> >>> -- Interfacing details for package Blarch: >>> Foo_External_Name : constant String := "..."; >>> Bar_External_Name : constant String := "..."; >>> >>> ... >>> end Target_Specific; >>> >>> And then have separate versions of the package for the various targets >>> supported. >> And to ease porting, have a package called Target_Specific_Windows, >> another one called Target_Specific_Linux. All the users do: >> with Target_Specific; >> >> and have the following library-lever renaming: >> with Target_Specific_Windows; >> package Target_Specific renames Target_Specific_Windows; > > I don't see what advantage such as a library-level renaming gives. If > one is developing for several platforms, say Windows and Linux, there > will then be two library-level renamings somewhere, one as above and the > other using Target_Specific_Linux, but some compiler-specific way is > still needed to choose which of the library level renamings to include > in the compilation. So one could just as well call both the > target-specific packages Target_Specific, directly, and use the same > compiler-specific way to choose which one to compile. For example, I use > GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows") > which contains the version of Target_Specific to be compiled. > > Would there be some sense in being able to specify such library-level > renamings as configuration pragmas? This might give us a standard way to > choose component versions depending on the configuration (leaving as > compiler-specific the way to select which configuration is to be > compiled... :-) I have issues with this approach in general. The problem is that there is no any check that the interfaces of the target-specific packages are same in the sense that all target-independent clients were compilable with any "implementation." In my projects I, of course, use neither pragmas nor renaming. It is too clumsy and unmaintainable. I simply put same named package into different target-specific directories, e.g. x86/windows or i686/linux and switch them using gpr scenario. This does not solve the abovementioned problem, though. As a possible solution, without introducing some huge stuff of formal package interfaces [*], it would be enough to be able to switch only the private part of the specification and the package body, keeping the public part same. It would not work with target-specific constants and conditionally with-ed packages. ----------------------- * Much needed for generic formal packages, though. But this is a different story. BTW, target-specific packages could be considered instances of some virtual generic package with target as an actual parameter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 8:55 ` Dmitry A. Kazakov @ 2014-05-27 15:45 ` G.B. 2014-05-27 16:41 ` Dmitry A. Kazakov 2014-05-27 22:57 ` Randy Brukardt 0 siblings, 2 replies; 13+ messages in thread From: G.B. @ 2014-05-27 15:45 UTC (permalink / raw) On 27.05.14 10:55, Dmitry A. Kazakov wrote: > On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote: > >> On 14-05-27 08:16 , J-P. Rosen wrote: >>> Le 23/05/2014 23:21, Randy Brukardt a écrit : (I hadn't seen Randy Brukardt's original reply in my news reader, sorry for responding late. (And I should have mentioned Link_Name, not Linker_Options.)) >> Would there be some sense in being able to specify such library-level >> renamings as configuration pragmas? This might give us a standard way to >> choose component versions depending on the configuration (leaving as >> compiler-specific the way to select which configuration is to be >> compiled... :-) A configuration pragma seems to have the property that just one may cover many units, whereas library level renamings lack this formal connection, and there may be many. (Directories, or discipline, providing for a more or less formal mode of development.) When the compiler knows about "representation units" (I think Bob Duff once mentioned such a thing using this name), and the language ties them to (the private part of) a unit, then at least programmers will have something explicit and reliable, issues notwithstanding: > I have issues with this approach in general. The problem is that there is > no any check that the interfaces of the target-specific packages are same > in the sense that all target-independent clients were compilable with any > "implementation." Assuming that a universal expression of "compilability" in any configuration is nice, but likely impossible, would you still think that what Randy has called a semantics-denying fiction could be preserved for some aspects? For example, procedure Doubled (X : in out Natural) with Post => (if X'Old <= Natural'Last / 2 then X = X'Old * 2 else False), Import, External_Name => "d2"; If the External_Name aspect of Doubled were moved to a representation unit tied to whatever Doubled lives in, then developing the program that calls Doubled should work up to a point, namely when Natural's representation finally matters. And doesn't it matter now, in any case, when porting (configuring)? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 15:45 ` G.B. @ 2014-05-27 16:41 ` Dmitry A. Kazakov 2014-05-27 16:52 ` G.B. 2014-05-27 22:57 ` Randy Brukardt 1 sibling, 1 reply; 13+ messages in thread From: Dmitry A. Kazakov @ 2014-05-27 16:41 UTC (permalink / raw) On Tue, 27 May 2014 17:45:07 +0200, G.B. wrote: > On 27.05.14 10:55, Dmitry A. Kazakov wrote: >> I have issues with this approach in general. The problem is that there is >> no any check that the interfaces of the target-specific packages are same >> in the sense that all target-independent clients were compilable with any >> "implementation." > > Assuming that a universal expression of "compilability" in any > configuration is nice, but likely impossible, It is surely possible at the same level of scrutiny the language mandates certain programs legal <=> compilable. > would you still think > that what Randy has called a semantics-denying fiction could > be preserved for some aspects? For example, > > procedure Doubled (X : in out Natural) > with Post => (if > X'Old <= Natural'Last / 2 > then > X = X'Old * 2 > else > False), > Import, > External_Name => "d2"; > > If the External_Name aspect of Doubled were moved to > a representation unit tied to whatever Doubled lives in, That is what I suggested. I don't care about aspects, there is no such thing in real-life at all. There are specifications and implementations, nothing else. External_Name certainly belongs to the implementation as any definition of a body does. No difference. So if you moved it to the implementation and then switched implementations with the targets, that will be all OK to me. Some implementations could have a proper body of Doubled. > then developing the program that calls Doubled should work > up to a point, namely when Natural's representation finally > matters. It never matters if post-condition you wrote was meant proper post-condition = checked at compile time. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 16:41 ` Dmitry A. Kazakov @ 2014-05-27 16:52 ` G.B. 2014-05-27 17:03 ` Dmitry A. Kazakov 0 siblings, 1 reply; 13+ messages in thread From: G.B. @ 2014-05-27 16:52 UTC (permalink / raw) On 27.05.14 18:41, Dmitry A. Kazakov wrote: > It never matters if post-condition you wrote was meant proper > post-condition = checked at compile time. I meant to refer to the effects of the rep aspects: Import can surely break contracts, practically, if the external entity has no notion of Natural'Last? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 16:52 ` G.B. @ 2014-05-27 17:03 ` Dmitry A. Kazakov 0 siblings, 0 replies; 13+ messages in thread From: Dmitry A. Kazakov @ 2014-05-27 17:03 UTC (permalink / raw) On Tue, 27 May 2014 18:52:44 +0200, in comp.lang.ada you wrote: > On 27.05.14 18:41, Dmitry A. Kazakov wrote: >> It never matters if post-condition you wrote was meant proper >> post-condition = checked at compile time. > > I meant to refer to the effects of the rep aspects: > > Import can surely break contracts, practically, if > the external entity has no notion of Natural'Last? No, it cannot. The contract proper is checked at compile-, latest static linkage-time. You cannot state a contract in terms of Natural'Last if you don't have Natural'Last. The thing you used to call "contract" is merely behavior. It can be any if unspecified => it does not matter => nothing broken. If specified, then the only way to do so formally is per a contract proper. (Informal contract are not a language issue. They are enforced through code reviews, testing etc.) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: spec/body/rep (Was: Compilation error (GNAT bug?)) 2014-05-27 15:45 ` G.B. 2014-05-27 16:41 ` Dmitry A. Kazakov @ 2014-05-27 22:57 ` Randy Brukardt 1 sibling, 0 replies; 13+ messages in thread From: Randy Brukardt @ 2014-05-27 22:57 UTC (permalink / raw) "G.B." <rm-dash-bau-haus@dash.futureapps.de> wrote in message news:5384b302$0$6663$9b4e6d93@newsspool3.arcor-online.net... ... > When the compiler knows about "representation units" (I think Bob Duff > once mentioned such a thing using this name), and the language ties > them to (the private part of) a unit, then at least programmers will > have something explicit and reliable, issues notwithstanding: But this solves nothing. There has to be some implementation-defined (or project-defined) way of selecting which "representation unit" is selected for a particular compilation. And that's the problem, with any of these solutions. (I agree with Dmitry about the problem of keeping the versions of the packages in sync. I believe this has to be solved by the version-control; one of the reasons that I find typical VCs useless is that they refuse to solve that problem and solve other unlikely problems instead.) In any case, adding a new kind of unit would require sweeping changes to the language standard and to implementations. It would require a pretty significant problem to even consider such a change. We did in fact consider that for the mutually-dependent package problem, but ultimately decided to avoid it in favor of the "virtual" limited view solution. If we're unwilling to use such a solution to solve a critical problem, I can hardly imagine using it to solve a problem that's not hard to solve with some tools (as with Dmitry's project manager solution) or discipline (as in J-P's comment in or out of a library-level renames). Randy. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-05-27 22:57 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-20 18:32 Compilation error (GNAT bug?) Victor Porton 2014-05-20 18:43 ` Simon Wright 2014-05-20 22:22 ` spec/body/rep (Was: Compilation error (GNAT bug?)) Georg Bauhaus 2014-05-23 21:21 ` Randy Brukardt 2014-05-27 5:16 ` J-P. Rosen 2014-05-27 6:22 ` Niklas Holsti 2014-05-27 8:54 ` J-P. Rosen 2014-05-27 8:55 ` Dmitry A. Kazakov 2014-05-27 15:45 ` G.B. 2014-05-27 16:41 ` Dmitry A. Kazakov 2014-05-27 16:52 ` G.B. 2014-05-27 17:03 ` Dmitry A. Kazakov 2014-05-27 22:57 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox