* pragma/aspect Import, Convention parameters
@ 2015-08-13 8:27 Dmitry A. Kazakov
2015-08-13 10:24 ` G.B.
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Dmitry A. Kazakov @ 2015-08-13 8:27 UTC (permalink / raw)
Why is it an identifier?
For writing portable code it should be a static expression. The problem is
that much too often the exported functions of the same library have
different conventions on different platforms, e.g.
procedure Foo ...
pragma Import (C, Foo, "Foo"); -- Linux
procedure Foo ...
pragma Import (StdCall, Foo, "_Foo"); -- Windows
The external name is an expression. Thus you could write something like
pragma Import (..., Foo, Target.External_Name_Prefix & "Foo");
With External_Name_Prefix defined in a single configuration packet Target
to change. But the convention is not an expression.
There certainly are ways to keep it backward compatible, e.g.
procedure Foo ...
pragma Import (User, Foo, "Foo", "Stdcall");
procedure Foo ... with Convention_Name => "StdCall", ...
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 8:27 pragma/aspect Import, Convention parameters Dmitry A. Kazakov
@ 2015-08-13 10:24 ` G.B.
2015-08-13 11:52 ` Dmitry A. Kazakov
2015-08-13 20:32 ` Randy Brukardt
2015-08-13 23:42 ` David Botton
2 siblings, 1 reply; 14+ messages in thread
From: G.B. @ 2015-08-13 10:24 UTC (permalink / raw)
On 13.08.15 10:27, Dmitry A. Kazakov wrote:
> But the convention is not an expression.
Maybe reflecting the approaches taken by a compiler
(code generation) vs that of the component that handles
names and locations of external routines (later)?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 10:24 ` G.B.
@ 2015-08-13 11:52 ` Dmitry A. Kazakov
0 siblings, 0 replies; 14+ messages in thread
From: Dmitry A. Kazakov @ 2015-08-13 11:52 UTC (permalink / raw)
On Thu, 13 Aug 2015 12:24:22 +0200, G.B. wrote:
> On 13.08.15 10:27, Dmitry A. Kazakov wrote:
>> But the convention is not an expression.
>
> Maybe reflecting the approaches taken by a compiler
> (code generation) vs that of the component that handles
> names and locations of external routines (later)?
It does not matter since both are static anyway.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 8:27 pragma/aspect Import, Convention parameters Dmitry A. Kazakov
2015-08-13 10:24 ` G.B.
@ 2015-08-13 20:32 ` Randy Brukardt
2015-08-14 7:23 ` Dmitry A. Kazakov
2015-08-13 23:42 ` David Botton
2 siblings, 1 reply; 14+ messages in thread
From: Randy Brukardt @ 2015-08-13 20:32 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
> Why is it an identifier?
Dunno. That's what Ada 95 defined, and we've never had a request to change
it.
In my experience (which is mostly with rather low-level stuff), there is a
lot more different than just the convention when changing between Linux and
Windows (subprogram names, parameter values, etc.) So it's not much of a
hardship to use separate thin bindings for each -- the differences are
reconciled in the thick binding anyway.
The problem with such an approach is that conventional version control
doesn't work very well with it; one needs to control individual blocks with
some different and many being shared. Ideally, changes in shared parts would
be reflected in all of the related versions of each package, while changes
in the unshared parts would not.
We never found a solution to this for Janus/Ada (which has this problem in
many modules); we extracted some host and target dependencies into dedicated
packages, but many of them are not so simple and need to be described in
code. We ended up with a version control overlay which manages the
relationships between the different versions, so that a change in one
version would trigger a request to check if the other versions needed
similar updates (they usually do). But that checking had to be done
manually.
We side-stepped the problem for Claw by not supporting any other targets
than Windows. :-) It would have been a lot worse had we wanted to support
(say) GTK on Linux.
Randy.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 8:27 pragma/aspect Import, Convention parameters Dmitry A. Kazakov
2015-08-13 10:24 ` G.B.
2015-08-13 20:32 ` Randy Brukardt
@ 2015-08-13 23:42 ` David Botton
2015-08-15 5:22 ` gautier_niouzes
2 siblings, 1 reply; 14+ messages in thread
From: David Botton @ 2015-08-13 23:42 UTC (permalink / raw)
In GWindows I used expressions based on the Win32 API that one chose to support. Windows has a duplicate Ansi and UNICODE set of APIs. It worked out well. If one wanted to go beyond that use the same approach used for any multi language (English / Chinese / etc) support, string tables.
David Botton
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 20:32 ` Randy Brukardt
@ 2015-08-14 7:23 ` Dmitry A. Kazakov
2015-08-14 20:30 ` Randy Brukardt
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry A. Kazakov @ 2015-08-14 7:23 UTC (permalink / raw)
On Thu, 13 Aug 2015 15:32:23 -0500, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
>> Why is it an identifier?
>
> Dunno. That's what Ada 95 defined, and we've never had a request to change
> it.
Maybe now? It is not a big change and as much as I hate if-then-else
expressions they could be handy here.
> In my experience (which is mostly with rather low-level stuff), there is a
> lot more different than just the convention when changing between Linux and
> Windows (subprogram names, parameter values, etc.)
In these days most upper level libraries are more or less compatible
regarding their API. The main problem is actually names and conventions
because most of them have them build with Visual C for the Windows part and
mimic Windows API, which are StdCall.
> So it's not much of a
> hardship to use separate thin bindings for each -- the differences are
> reconciled in the thick binding anyway.
Keeping two versions of *.ads is excessive and a hell of maintenance.
Independently of whether you have thick bindings or not, you have to have
thin bindings first.
> The problem with such an approach is that conventional version control
> doesn't work very well with it; one needs to control individual blocks with
> some different and many being shared. Ideally, changes in shared parts would
> be reflected in all of the related versions of each package, while changes
> in the unshared parts would not.
Yes, that is the problem. The Ada bindings sources are practically same up
to the pragma Import part.
> We side-stepped the problem for Claw by not supporting any other targets
> than Windows. :-) It would have been a lot worse had we wanted to support
> (say) GTK on Linux.
Yes.
However GTK is not a big problem because it has same external names under
Windows and Linux. For really few exceptions GTK's GIO had I used GCC
linker weak references to avoid contamination of *.ads files.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-14 7:23 ` Dmitry A. Kazakov
@ 2015-08-14 20:30 ` Randy Brukardt
2015-08-15 1:15 ` Shark8
0 siblings, 1 reply; 14+ messages in thread
From: Randy Brukardt @ 2015-08-14 20:30 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1xhfjepw437zd.137i8eiplc5lt.dlg@40tude.net...
> On Thu, 13 Aug 2015 15:32:23 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
>>> Why is it an identifier?
>>
>> Dunno. That's what Ada 95 defined, and we've never had a request to
>> change
>> it.
>
> Maybe now? It is not a big change and as much as I hate if-then-else
> expressions they could be handy here.
As always, send a description of the problem and proposed solution (not just
the solution, 'cause that will just get put in the dusty drawer never to be
seen again) to Ada-Comment and it most likely will get considered.
>> In my experience (which is mostly with rather low-level stuff), there is
>> a
>> lot more different than just the convention when changing between Linux
>> and
>> Windows (subprogram names, parameter values, etc.)
>
> In these days most upper level libraries are more or less compatible
> regarding their API. The main problem is actually names and conventions
> because most of them have them build with Visual C for the Windows part
> and
> mimic Windows API, which are StdCall.
That's of course the difference in our experience. I'd almost never use
"upper-level libraries" for anything; I want as much code as possible that I
can fix (which means it has to be Ada code at least nominally in our
control). That's why Claw is the sort of binding that it is, directly to
Win32.
>> So it's not much of a
>> hardship to use separate thin bindings for each -- the differences are
>> reconciled in the thick binding anyway.
>
> Keeping two versions of *.ads is excessive and a hell of maintenance.
> Independently of whether you have thick bindings or not, you have to have
> thin bindings first.
Right. It *is* a hell of a lot of maintenance -- that goes with the
territory -- and no one wants to build tools that help. (Conventional
version control is actively harmful in this, and the C "solution" of a
preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of
course, it's possible that one *cannot* write a usable tool that would help
(I wasn't able to solve the problem adequately for our own use, and I have
tried).
...
>> We side-stepped the problem for Claw by not supporting any other targets
>> than Windows. :-) It would have been a lot worse had we wanted to support
>> (say) GTK on Linux.
>
> Yes.
>
> However GTK is not a big problem because it has same external names under
> Windows and Linux. For really few exceptions GTK's GIO had I used GCC
> linker weak references to avoid contamination of *.ads files.
There is no way we would have used GTK on Windows. The entire purpose of
Claw was to give applications the Windows native look-and-feel. I've yet to
see any GTK application that comes remotely close.
A Linux version of Claw would have existed to emulate as much of that
Windows look-and-feel as possible on Linux. I probably would have based it
on GTK as X11 is a nightmare, but it would have been insane to run a program
that *emulated* the Windows look-and-feel on Windows when a simple
recompile/relink would have given one the actual look-and-feel.
But I've actually been leaning toward the "portable" version of Claw being
based in some way on HTML -- essentially what David Botton has been doing
with Gnoga. (So it probably will never happen, as there doesn't seem like
there would be any reason.)
Randy.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-14 20:30 ` Randy Brukardt
@ 2015-08-15 1:15 ` Shark8
2015-08-17 21:40 ` Randy Brukardt
0 siblings, 1 reply; 14+ messages in thread
From: Shark8 @ 2015-08-15 1:15 UTC (permalink / raw)
On Friday, August 14, 2015 at 2:30:29 PM UTC-6, Randy Brukardt wrote:
>
> Right. It *is* a hell of a lot of maintenance -- that goes with the
> territory -- and no one wants to build tools that help. (Conventional
> version control is actively harmful in this, and the C "solution" of a
> preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of
> course, it's possible that one *cannot* write a usable tool that would help
> (I wasn't able to solve the problem adequately for our own use, and I have
> tried).
I don't know, it sounds kind of like (tangentially, albeit) something that Wulf's IDL would address? I'm actually starting work on something that could address this issue... but I would love to get your opinion/input.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-13 23:42 ` David Botton
@ 2015-08-15 5:22 ` gautier_niouzes
2015-08-17 21:54 ` Randy Brukardt
0 siblings, 1 reply; 14+ messages in thread
From: gautier_niouzes @ 2015-08-15 5:22 UTC (permalink / raw)
Le vendredi 14 août 2015 01:42:30 UTC+2, David Botton a écrit :
> In GWindows I used expressions based on the Win32 API that one chose to support. Windows has a duplicate Ansi and UNICODE set of APIs. It worked out well.
It work*s*, and to the full satisfaction of its users :-) !
To be more concrete, GWindows spec. has this (the file gwindows.ads depends on whether ANSI or UNICODE is used):
Character_Mode_Identifier : constant String := "W";
and there are at hundreds of places in children packages:
procedure GetTextMetrics
(HDC : in GWindows.Types.Handle;
M : out Font_Metrics_W);
pragma Import (StdCall, GetTextMetrics,
"GetTextMetrics" & Character_Mode_Identifier);
So, having the convention as a string could be helpful if one needs to switch between C and StdCall as well.
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-15 1:15 ` Shark8
@ 2015-08-17 21:40 ` Randy Brukardt
2015-08-17 21:47 ` Bob Duff
2015-08-20 16:00 ` Shark8
0 siblings, 2 replies; 14+ messages in thread
From: Randy Brukardt @ 2015-08-17 21:40 UTC (permalink / raw)
"Shark8" <onewingedshark@gmail.com> wrote in message
news:9c4e3390-6fcd-4130-a001-76d459cf460c@googlegroups.com...
> On Friday, August 14, 2015 at 2:30:29 PM UTC-6, Randy Brukardt wrote:
>>
>> Right. It *is* a hell of a lot of maintenance -- that goes with the
>> territory -- and no one wants to build tools that help. (Conventional
>> version control is actively harmful in this, and the C "solution" of a
>> preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of
>> course, it's possible that one *cannot* write a usable tool that would
>> help
>> (I wasn't able to solve the problem adequately for our own use, and I
>> have
>> tried).
>
> I don't know, it sounds kind of like (tangentially, albeit) something that
> Wulf's IDL would address? I'm actually starting work on something that
> could address this issue... but I would love to get your opinion/input.
Dunno. Do you have a reference to "Wulf's IDL"?
Randy.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-17 21:40 ` Randy Brukardt
@ 2015-08-17 21:47 ` Bob Duff
2015-08-20 16:00 ` Shark8
1 sibling, 0 replies; 14+ messages in thread
From: Bob Duff @ 2015-08-17 21:47 UTC (permalink / raw)
"Randy Brukardt" <randy@rrsoftware.com> writes:
> Dunno. Do you have a reference to "Wulf's IDL"?
Google "Wulf IDL" seems to give some info. This is the IDL that was
used to define the original DIANA. Not to be confused with CORBA IDL,
which has a similar purpose, but is completely different.
- Bob
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-15 5:22 ` gautier_niouzes
@ 2015-08-17 21:54 ` Randy Brukardt
2015-08-20 16:07 ` Shark8
0 siblings, 1 reply; 14+ messages in thread
From: Randy Brukardt @ 2015-08-17 21:54 UTC (permalink / raw)
<gautier_niouzes@hotmail.com> wrote in message
news:2d5be9db-145c-4f96-ba94-18b73b82d532@googlegroups.com...
...
> So, having the convention as a string could be helpful if one needs to
> switch between C and StdCall as well.
Obviously, it would work (I don't think anyone would doubt that), and it
would solve the postulated problem. But would it cause more problems that it
fixed??
Specifically, the problem would be doing that without introducing a
compatibility problem.
Right now, a convention is an "identifier specific to an aspect" (or
pragma). It is *not* resolved.
To make it a string expression would require having it resolved. Depending
upon the mechanism used, that could be a significant compatibility problem
with existing code.
For instance, one possibility would be for the existing constants to be
declared somewhere as string constants:
C : constant String := "C";
StdCall : constant String := "StdCall";
...
Standard is the obvious place, but that has serious implications beyond
these constants. Even so, let's assume it is there and ignore the effect on
other visibility for the moment. Even ignoring the problems raised by
visibility of things in Standard, it still would cause incompatibilities:
package Foo is
C : constant Integer := 10;
A : array (1 .. C) of Integer with Convention => C; -- (1)
procedure B (N : in Integer) with Convention => C; -- (2)
...
end Foo;
If Convention is a string expression resolved in the normal way,
declarations (1) and (2) are illegal (the local C is visible rather than the
ones in Standard). But they're currently legal Ada.
And of course, there would be the ever-popular:
package Ugh is
Stdcall : constant String := "C";
procedure P (N : in Integer) with Convention => Stdcall;
end Ugh;
Where the meaning would be different in Ada 95-2012 and a hypothetical new
Ada where convention would be a String.
There may be a way around these issues (one obvious one would be to have a
new aspect for this purpose, rather than trying to reuse the existing one),
but this is not an open-and-shut improvement. (Breaking existing Ada code is
a non-starter for obvious reasons.)
Randy.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-17 21:40 ` Randy Brukardt
2015-08-17 21:47 ` Bob Duff
@ 2015-08-20 16:00 ` Shark8
1 sibling, 0 replies; 14+ messages in thread
From: Shark8 @ 2015-08-20 16:00 UTC (permalink / raw)
On Monday, August 17, 2015 at 3:40:38 PM UTC-6, Randy Brukardt wrote:
>
> Dunno. Do you have a reference to "Wulf's IDL"?
Yes... but it's paper.
ISBN: 0-7167-8198-0
The original paper is here: http://repository.cmu.edu/cgi/viewcontent.cgi?article=3445&context=compsci (should be reachable by this page: http://repository.cmu.edu/compsci/2412/) -- the document's own page 8 [PDF page 14] lists 'precision' and 'maintainability' as goals.
(The book is for a later development of IDL.)
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: pragma/aspect Import, Convention parameters
2015-08-17 21:54 ` Randy Brukardt
@ 2015-08-20 16:07 ` Shark8
0 siblings, 0 replies; 14+ messages in thread
From: Shark8 @ 2015-08-20 16:07 UTC (permalink / raw)
On Monday, August 17, 2015 at 3:54:31 PM UTC-6, Randy Brukardt wrote:
> <gautier_niouzes> wrote in message
> ...
> > So, having the convention as a string could be helpful if one needs to
> > switch between C and StdCall as well.
>
> Obviously, it would work (I don't think anyone would doubt that), and it
> would solve the postulated problem. But would it cause more problems that it
> fixed??
>
> Specifically, the problem would be doing that without introducing a
> compatibility problem.
>
> Right now, a convention is an "identifier specific to an aspect" (or
> pragma). It is *not* resolved.
>
> To make it a string expression would require having it resolved. Depending
> upon the mechanism used, that could be a significant compatibility problem
> with existing code.
>
> For instance, one possibility would be for the existing constants to be
> declared somewhere as string constants:
>
> C : constant String := "C";
> StdCall : constant String := "StdCall";
> ...
>
> Standard is the obvious place, but that has serious implications beyond
> these constants. Even so, let's assume it is there and ignore the effect on
> other visibility for the moment. Even ignoring the problems raised by
> visibility of things in Standard, it still would cause incompatibilities:
>
> package Foo is
> C : constant Integer := 10;
> A : array (1 .. C) of Integer with Convention => C; -- (1)
> procedure B (N : in Integer) with Convention => C; -- (2)
> ...
> end Foo;
>
> If Convention is a string expression resolved in the normal way,
> declarations (1) and (2) are illegal (the local C is visible rather than the
> ones in Standard). But they're currently legal Ada.
>
> And of course, there would be the ever-popular:
>
> package Ugh is
> Stdcall : constant String := "C";
> procedure P (N : in Integer) with Convention => Stdcall;
> end Ugh;
>
> Where the meaning would be different in Ada 95-2012 and a hypothetical new
> Ada where convention would be a String.
>
> There may be a way around these issues (one obvious one would be to have a
> new aspect for this purpose, rather than trying to reuse the existing one),
> but this is not an open-and-shut improvement. (Breaking existing Ada code is
> a non-starter for obvious reasons.)
>
> Randy.
One problem is that as a string now you have an explosion of possible conventions, most of which are invalid. (There's also the issue of whether the string's statically known, which it ought to be for the compiler to work properly at compile-time... but something about strings rubs me the wrong way here. [I suppose it's because I consider some enumeration to be a far better modeling of the problem.])
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-08-20 16:07 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-13 8:27 pragma/aspect Import, Convention parameters Dmitry A. Kazakov
2015-08-13 10:24 ` G.B.
2015-08-13 11:52 ` Dmitry A. Kazakov
2015-08-13 20:32 ` Randy Brukardt
2015-08-14 7:23 ` Dmitry A. Kazakov
2015-08-14 20:30 ` Randy Brukardt
2015-08-15 1:15 ` Shark8
2015-08-17 21:40 ` Randy Brukardt
2015-08-17 21:47 ` Bob Duff
2015-08-20 16:00 ` Shark8
2015-08-13 23:42 ` David Botton
2015-08-15 5:22 ` gautier_niouzes
2015-08-17 21:54 ` Randy Brukardt
2015-08-20 16:07 ` Shark8
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox