* Vulkan is here! @ 2016-02-17 15:37 olivier.henley 2016-02-17 20:31 ` Randy Brukardt 2016-02-17 22:37 ` Luke A. Guest 0 siblings, 2 replies; 30+ messages in thread From: olivier.henley @ 2016-02-17 15:37 UTC (permalink / raw) :) https://www.khronos.org/vulkan/ https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 15:37 Vulkan is here! olivier.henley @ 2016-02-17 20:31 ` Randy Brukardt 2016-02-17 22:37 ` Luke A. Guest 2016-02-17 23:26 ` olivier.henley 2016-02-17 22:37 ` Luke A. Guest 1 sibling, 2 replies; 30+ messages in thread From: Randy Brukardt @ 2016-02-17 20:31 UTC (permalink / raw) Does it have anything (directly) to do with Ada? I couldn't find anything in a quick look. Randy. P.S. I ask, of course, to see if there is anything that needs to be linked on AdaIC. Not trying to be a pain in some body part. ;-) <olivier.henley@gmail.com> wrote in message news:bf1c421d-0fce-417a-8ace-c5f1581b7597@googlegroups.com... > :) > > https://www.khronos.org/vulkan/ > https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 20:31 ` Randy Brukardt @ 2016-02-17 22:37 ` Luke A. Guest 2016-02-17 23:26 ` olivier.henley 1 sibling, 0 replies; 30+ messages in thread From: Luke A. Guest @ 2016-02-17 22:37 UTC (permalink / raw) Randy Brukardt <randy@rrsoftware.com> wrote: > Does it have anything (directly) to do with Ada? I couldn't find anything in > a quick look. > > Randy. > > P.S. I ask, of course, to see if there is anything that needs to be linked > on AdaIC. Not trying to be a pain in some body part. ;-) > > <olivier.henley@gmail.com> wrote in message > news:bf1c421d-0fce-417a-8ace-c5f1581b7597@googlegroups.com... >> :) >> >> https://www.khronos.org/vulkan/ >> https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf > > > Not yet ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 20:31 ` Randy Brukardt 2016-02-17 22:37 ` Luke A. Guest @ 2016-02-17 23:26 ` olivier.henley 1 sibling, 0 replies; 30+ messages in thread From: olivier.henley @ 2016-02-17 23:26 UTC (permalink / raw) On Wednesday, February 17, 2016 at 3:31:20 PM UTC-5, Randy Brukardt wrote: > Does it have anything (directly) to do with Ada? I couldn't find anything in > a quick look. > > Randy. > > P.S. I ask, of course, to see if there is anything that needs to be linked > on AdaIC. Not trying to be a pain in some body part. ;-) As you probably know it is the next OpenGL and has nothing to do with Ada per se. Sorry for spamming... but IMO, it is great news for computing in general. :) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 15:37 Vulkan is here! olivier.henley 2016-02-17 20:31 ` Randy Brukardt @ 2016-02-17 22:37 ` Luke A. Guest 2016-02-17 23:56 ` olivier.henley 1 sibling, 1 reply; 30+ messages in thread From: Luke A. Guest @ 2016-02-17 22:37 UTC (permalink / raw) <olivier.henley@gmail.com> wrote: > :) > > https://www.khronos.org/vulkan/ > https://www.khronos.org/registry/vulkan/specs/1.0/refguide/Vulkan-1.0-web.pdf > Yup was quite a surprise yesterday at 3! It's something I've been planing on binding. It's bigger than I expected, just look at API overview card, 13 pages! ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 22:37 ` Luke A. Guest @ 2016-02-17 23:56 ` olivier.henley 2016-02-18 0:20 ` Olivier Henley ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: olivier.henley @ 2016-02-17 23:56 UTC (permalink / raw) On Wednesday, February 17, 2016 at 5:37:16 PM UTC-5, Luke A. Guest wrote: > Yup was quite a surprise yesterday at 3! > > It's something I've been planing on binding. It's bigger than I expected, > just look at API overview card, 13 pages! I would really like to help you with that but my mileage to translate C stuff is limited. In my spare time I'm "augmenting" a one-to-one binding to xlib because suprisingly I found only half implementations here and there. p.s: I dont get it why people don't systematically make a thin binding, standalone, and then undertake any other Ada-ized layer over it separately. I hate extracting stuff from others "wool ball". ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 23:56 ` olivier.henley @ 2016-02-18 0:20 ` Olivier Henley 2016-02-18 1:22 ` Luke A. Guest 2016-02-19 4:21 ` thick bindings, was " tmoran 2 siblings, 0 replies; 30+ messages in thread From: Olivier Henley @ 2016-02-18 0:20 UTC (permalink / raw) On Wednesday, February 17, 2016 at 6:56:23 PM UTC-5, Olivier Henley wrote: > uprisingly I found only half implementations here and there. I'm lying, the one from Intermetrics was complete. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-17 23:56 ` olivier.henley 2016-02-18 0:20 ` Olivier Henley @ 2016-02-18 1:22 ` Luke A. Guest 2016-02-18 15:58 ` Olivier Henley 2016-02-19 4:21 ` thick bindings, was " tmoran 2 siblings, 1 reply; 30+ messages in thread From: Luke A. Guest @ 2016-02-18 1:22 UTC (permalink / raw) <olivier.henley@gmail.com> wrote: > On Wednesday, February 17, 2016 at 5:37:16 PM UTC-5, Luke A. Guest wrote: >> Yup was quite a surprise yesterday at 3! >> >> It's something I've been planing on binding. It's bigger than I expected, >> just look at API overview card, 13 pages! > > I would really like to help you with that but my mileage to translate C > stuff is limited. In my spare time I'm "augmenting" a one-to-one binding > to xlib because suprisingly I found only half implementations here and there. I need to look through the vk.xml and the readme.pdf properly, I've only skimmed it. If it's similar enough to to the GL XML file I'll extend my GL binding generator to do it. I've actually not finished the GL binding generator yet 😖 Otherwise I'll likely think about extending their scripts as it would be nice to try to get the Ada stuff folded back into the original source and add documentation as well. > > p.s: I dont get it why people don't systematically make a thin binding, > standalone, and then undertake any other Ada-ized layer over it > separately. I hate extracting stuff from others "wool ball". Because it's nicer to use a thick binding over thin ones. Luke ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-18 1:22 ` Luke A. Guest @ 2016-02-18 15:58 ` Olivier Henley 2016-02-18 18:32 ` Per Sandberg 0 siblings, 1 reply; 30+ messages in thread From: Olivier Henley @ 2016-02-18 15:58 UTC (permalink / raw) On Wednesday, February 17, 2016 at 8:22:43 PM UTC-5, Luke A. Guest wrote: > Because it's nicer to use a thick binding over thin ones. > > Luke It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-18 15:58 ` Olivier Henley @ 2016-02-18 18:32 ` Per Sandberg 2016-02-18 23:21 ` Simon Wright 0 siblings, 1 reply; 30+ messages in thread From: Per Sandberg @ 2016-02-18 18:32 UTC (permalink / raw) Well i'd put an hour on the "problem" to get a complete lowlevel binding and it is correct with all methods and and constants and is now in github ready to be extended with some highlevel stuff. https://github.com/persan/a-vulkan /Per Den 2016-02-18 kl. 16:58, skrev Olivier Henley: > On Wednesday, February 17, 2016 at 8:22:43 PM UTC-5, Luke A. Guest wrote: >> Because it's nicer to use a thick binding over thin ones. >> >> Luke > > It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. > > A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others. > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-18 18:32 ` Per Sandberg @ 2016-02-18 23:21 ` Simon Wright 2016-02-19 5:14 ` Per Sandberg 0 siblings, 1 reply; 30+ messages in thread From: Simon Wright @ 2016-02-18 23:21 UTC (permalink / raw) Per Sandberg <per.s.sandberg@bahnhof.se> writes: > Well i'd put an hour on the "problem" to get a complete lowlevel > binding and it is correct with all methods and and constants and is > now in github ready to be extended with some highlevel stuff. > > https://github.com/persan/a-vulkan You translate (~0U) as 0, but the ~ operator is bitwise-inversion, so ~0 is all-1s (in whatever length is appropriate). Hope the size indicators are correct; you could generate for instance VK_WHOLE_SIZE : constant Unsigned_64 := not 0; ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-18 23:21 ` Simon Wright @ 2016-02-19 5:14 ` Per Sandberg 2016-02-19 6:53 ` Per Sandberg 2016-02-19 8:20 ` Simon Wright 0 siblings, 2 replies; 30+ messages in thread From: Per Sandberg @ 2016-02-19 5:14 UTC (permalink / raw) Thanks missed that patch. It's corrected. /P Den 2016-02-19 kl. 00:21, skrev Simon Wright: > Unsigned_64 := not 0 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-19 5:14 ` Per Sandberg @ 2016-02-19 6:53 ` Per Sandberg 2016-02-19 8:20 ` Simon Wright 1 sibling, 0 replies; 30+ messages in thread From: Per Sandberg @ 2016-02-19 6:53 UTC (permalink / raw) The above miss highlights the danger of trusting humans for simple transformation of data. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-19 5:14 ` Per Sandberg 2016-02-19 6:53 ` Per Sandberg @ 2016-02-19 8:20 ` Simon Wright 2016-02-19 9:01 ` Per Sandberg 1 sibling, 1 reply; 30+ messages in thread From: Simon Wright @ 2016-02-19 8:20 UTC (permalink / raw) Per Sandberg <per.s.sandberg@bahnhof.se> writes: > Thanks missed that patch. > It's corrected. > /P > > > Den 2016-02-19 kl. 00:21, skrev Simon Wright: >> Unsigned_64 := not 0 I'm not sure that all of the constants are Unsigned_64? I'm not familiar with C constant qualifiers, but it's at least possible that (~0U) is Unsigned_32, (~0ULL) is Unsigned_64? This will depend on where the constants get used. I can't check this out, because OS X isn't supported. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-19 8:20 ` Simon Wright @ 2016-02-19 9:01 ` Per Sandberg 2016-02-19 12:05 ` Simon Wright 0 siblings, 1 reply; 30+ messages in thread From: Per Sandberg @ 2016-02-19 9:01 UTC (permalink / raw) That's the problem when going from an untyped language with MACROS to a typed language with constants. In my experience a working way to get the "types" correct is a to do a higher level of binding, that way those ambiguities usually sort them self out. /Per ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-19 9:01 ` Per Sandberg @ 2016-02-19 12:05 ` Simon Wright 2016-02-19 13:14 ` G.B. 0 siblings, 1 reply; 30+ messages in thread From: Simon Wright @ 2016-02-19 12:05 UTC (permalink / raw) Per Sandberg <persan.sandberg@gmail.com> writes: > That's the problem when going from an untyped language with MACROS to > a typed language with constants. > In my experience a working way to get the "types" correct is a to do a > higher level of binding, that way those ambiguities usually sort them > self out. Indeed. As an alternative translation, which allows the compiler to decide, function VK_WHOLE_SIZE return Unsigned_64 is (not 0); function VK_WHOLE_SIZE return Unsigned_32 is (not 0); function VK_WHOLE_SIZE return Unsigned_16 is (not 0); function VK_WHOLE_SIZE return Unsigned_8 is (not 0); ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Vulkan is here! 2016-02-19 12:05 ` Simon Wright @ 2016-02-19 13:14 ` G.B. 0 siblings, 0 replies; 30+ messages in thread From: G.B. @ 2016-02-19 13:14 UTC (permalink / raw) On 19.02.16 13:05, Simon Wright wrote: > As an alternative translation, which allows the compiler to decide, To let the compiler decide seems the Right Thing, insofar as this also reflects what C's int types are about. Of course, neither the C implementation nor the Ada implementation are free to decide at whim, because either language's type system has requirements for, respectively, int and Integer etc. There's also System.Word_Size on the Ada side; maybe the Ada compiler docs inform about the relation of that static constant to the (auto-convertible) C expression "~0" in context, allowing the definition of matching Ada types, or finding potential width errors in pre-C99 stdint C use. ^ permalink raw reply [flat|nested] 30+ messages in thread
* thick bindings, was Re: Vulkan is here! 2016-02-17 23:56 ` olivier.henley 2016-02-18 0:20 ` Olivier Henley 2016-02-18 1:22 ` Luke A. Guest @ 2016-02-19 4:21 ` tmoran 2016-02-19 13:07 ` Olivier Henley 2 siblings, 1 reply; 30+ messages in thread From: tmoran @ 2016-02-19 4:21 UTC (permalink / raw) > p.s: I dont get it why people don't systematically make a thin binding, > standalone, and then undertake any other Ada-ized layer over it > separately. I hate extracting stuff from others "wool ball". A thick binding, like any API, creates an abstraction intended to be easier and safer to program than coding at a lower level. If you don't like the abstraction, don't use it - it's straightforward to code the necessary lower level thin binding instead. A thick binding makes many assumptions about the state of the machine and coding at the thin binding level likely makes those invalid. Luring the programmer into trying to code at two different abstraction levels at the same time is not a kindness. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 4:21 ` thick bindings, was " tmoran @ 2016-02-19 13:07 ` Olivier Henley 2016-02-19 15:38 ` Alejandro R. Mosteo 2016-02-19 22:28 ` Randy Brukardt 0 siblings, 2 replies; 30+ messages in thread From: Olivier Henley @ 2016-02-19 13:07 UTC (permalink / raw) On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote: > A thick binding, like any API, creates an abstraction intended to be > easier and safer to program than coding at a lower level. If you don't > like the abstraction, don't use it - it's straightforward to code the > necessary lower level thin binding instead. > > A thick binding makes many assumptions about the state of the machine and > coding at the thin binding level likely makes those invalid. Luring the > programmer into trying to code at two different abstraction levels at > the same time is not a kindness. 1. I understand the goals of a thick binding. 2. I questioned its architecture. 3. I answered that previously: It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others. 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 13:07 ` Olivier Henley @ 2016-02-19 15:38 ` Alejandro R. Mosteo 2016-02-19 16:54 ` Lucretia 2016-02-19 22:28 ` Randy Brukardt 1 sibling, 1 reply; 30+ messages in thread From: Alejandro R. Mosteo @ 2016-02-19 15:38 UTC (permalink / raw) On 19/02/16 14:07, Olivier Henley wrote: > On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote: >> A thick binding, like any API, creates an abstraction intended to be >> easier and safer to program than coding at a lower level. If you don't >> like the abstraction, don't use it - it's straightforward to code the >> necessary lower level thin binding instead. >> >> A thick binding makes many assumptions about the state of the machine and >> coding at the thin binding level likely makes those invalid. Luring the >> programmer into trying to code at two different abstraction levels at >> the same time is not a kindness. > > 1. I understand the goals of a thick binding. > > 2. I questioned its architecture. > > 3. I answered that previously: It is "nicer" when you assume that every one swears by your coding paradigm (the one forced by the thick layer)... which is, I think, close minded. A standalone thin layer does not prevent anyone else from undertaking a thick layer over it and still retains freedom for others. > > 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats. And nowadays the thinnest of bindings should be even easier: http://www.adacore.com/adaanswers/gems/gem-59/ Not pretty IME though, but can be a start. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 15:38 ` Alejandro R. Mosteo @ 2016-02-19 16:54 ` Lucretia 2016-02-19 17:28 ` Per Sandberg 0 siblings, 1 reply; 30+ messages in thread From: Lucretia @ 2016-02-19 16:54 UTC (permalink / raw) On Friday, 19 February 2016 15:38:14 UTC, Alejandro R. Mosteo wrote: > On 19/02/16 14:07, Olivier Henley wrote: > > 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats. > > And nowadays the thinnest of bindings should be even easier: > http://www.adacore.com/adaanswers/gems/gem-59/ > > Not pretty IME though, but can be a start. If you've started reading the spec, you'll notice that creating a thick binding to Vulkan is going to be quite difficult due to the amount of locking involved. I intend to create a simple thin binding and then build of that after some experimentation. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 16:54 ` Lucretia @ 2016-02-19 17:28 ` Per Sandberg 2016-02-19 17:41 ` Lucretia 0 siblings, 1 reply; 30+ messages in thread From: Per Sandberg @ 2016-02-19 17:28 UTC (permalink / raw) Do you want top start from scratch or colaborate ? I would gladly give you write access to https://github.com/persan/a-vulkan. This is gem-59 generated stuff. /P Den 2016-02-19 kl. 17:54, skrev Lucretia: > On Friday, 19 February 2016 15:38:14 UTC, Alejandro R. Mosteo wrote: >> On 19/02/16 14:07, Olivier Henley wrote: > >>> 4. It is not THAT straightforward to make a pristine lower level thin binding as both Per Sandberg and Simon Wright have to exchange to clarify possible caveats. >> >> And nowadays the thinnest of bindings should be even easier: >> http://www.adacore.com/adaanswers/gems/gem-59/ >> >> Not pretty IME though, but can be a start. > > If you've started reading the spec, you'll notice that creating a thick binding to Vulkan is going to be quite difficult due to the amount of locking involved. > > I intend to create a simple thin binding and then build of that after some experimentation. > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 17:28 ` Per Sandberg @ 2016-02-19 17:41 ` Lucretia 2016-02-19 18:02 ` Lucretia 0 siblings, 1 reply; 30+ messages in thread From: Lucretia @ 2016-02-19 17:41 UTC (permalink / raw) This is a project I have been planning since it was announced. I've already started. I want Ada to have a decent Vulkan binding from the outset and not get left behind like we have with OpenGL (I still need to finish my binding generator for GL!). I'm still annoyed at AMD for having a Linux driver ready and the Windows driver is not fully comformant either. I do think a more collaborative operation would be better, but it needs someone who knows C a bit better to get the ball rolling. Plus there's more that just creating the binding, it has to have all the flags in place for compiling for other OSes due to the various window manager extensions. Luke. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 17:41 ` Lucretia @ 2016-02-19 18:02 ` Lucretia 2016-02-19 19:53 ` Per Sandberg 0 siblings, 1 reply; 30+ messages in thread From: Lucretia @ 2016-02-19 18:02 UTC (permalink / raw) I have no problem with collaboration. I'll put up what I have on Github and my plan and we can compare. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 18:02 ` Lucretia @ 2016-02-19 19:53 ` Per Sandberg 0 siblings, 0 replies; 30+ messages in thread From: Per Sandberg @ 2016-02-19 19:53 UTC (permalink / raw) Many thumbs up. Since I believe the all hands should try to join and collaborate, if your start-point is better then mine i gladly nuke mine ;) And put my thinking into yours. /P Den 2016-02-19 kl. 19:02, skrev Lucretia: > I have no problem with collaboration. I'll put up what I have on Github and my plan and we can compare. > ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 13:07 ` Olivier Henley 2016-02-19 15:38 ` Alejandro R. Mosteo @ 2016-02-19 22:28 ` Randy Brukardt 2016-02-19 23:32 ` Olivier Henley ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Randy Brukardt @ 2016-02-19 22:28 UTC (permalink / raw) "Olivier Henley" <olivier.henley@gmail.com> wrote in message news:66c5617d-49e6-40eb-9341-31c6664b1f6c@googlegroups.com... On Thursday, February 18, 2016 at 11:21:26 PM UTC-5, tmo...@acm.org wrote: > A thick binding, like any API, creates an abstraction intended to be > easier and safer to program than coding at a lower level. If you don't > like the abstraction, don't use it - it's straightforward to code the > necessary lower level thin binding instead. ... >2. I questioned its architecture. True thin bindings are trivial to make (and can be pretty much automated), but they completely lose any advantage to using Ada. Pretty much the only thing to do with a true thin-binding is use it to make a thicker binding, else you would be better off writing in C. (C has meager correctness checking, but you lose even that when you cross the boundary between languages. The use of Ada is actually a negative in such circumstances.) What I've often advocated in such circumstances is the creation of a "medium binding". That is, eliminate the visibility at C issues without changing the essense of the binding (thus existing examples can be used with it). We did that for Windows waaay back before Claw; in the Windows 3.1 timeframe we made a medium binding for essentially all of the Windows interface of the time. It use the same operations but eliminated various c-isms: (1) Routines were named with underscores; (2) Overloading was used rather than unions (this was before Unchecked_Union was invented); (3) Boolean failure results were mapped to exceptions; (4) In out parameters were used rather than access parameters as much as possible (this requires inspection of the API in many cases); (5) null-terminated strings were converted into normal Ada string parameters where possible; (6) enumeration types were used rather than sets of constants if the values were distinct. There probably were a few other changes that I've since forgotten. (Probably some typing was strengthened.) (1) probably is a matter of taste (I find it near impossible to type identifiers that don't have the words separated by underscores, YMMV), and more recent improvements in Ada mean that (2) and (4) probably get at least partially handled by automatic conversion. But (3), (5), and (6) are the essence of Ada; without at least that you are gaining nothing for the significant loss of checking. The important reason for having access to some low-level binding is so that one can directly translate examples into Ada. The idea is that a medium binding preserves that (one uses the same objects, same parameters [possibly better typed], same subprogram calls), but makes those calls more sensible Ada code, letting the compiler provide more help to the programmer.) In contrast, a thick binding like Claw uses a different, more Ada-like overall design. Which means that one has to use only Claw examples -- most foreign language material doesn't work (at least not without a lot of mental translation). I agree with you that hiding the original API to that level can be a problem if your application doesn't fit into it's model - or you can't figure out how to do what you want even though you have a C example in front of you. I would have preferred to concentrate on medium bindings, myself, but it didn't appear that we could sell such a thing (too hard to explain the value, especially to non-Ada programmers) so we wrote an ATIP-P proposal for Claw, not MAWB (Medium Ada Windows Binding). Which was accepted, so the route was cast... Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 22:28 ` Randy Brukardt @ 2016-02-19 23:32 ` Olivier Henley 2016-02-20 0:26 ` Luke A. Guest 2016-02-20 6:28 ` tmoran 2 siblings, 0 replies; 30+ messages in thread From: Olivier Henley @ 2016-02-19 23:32 UTC (permalink / raw) @Randy: I totally agree with you. Adapting is one thing, starting to directly cramp mecanics over the original (or change completely the paradigm of the API) ... and while at it not cover the whole api, is another. Then, sprinkle a little bit of "un-maintenance" and after a couple of years you get a UBIB (Useless Broken Incomplete Binding). :D ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 22:28 ` Randy Brukardt 2016-02-19 23:32 ` Olivier Henley @ 2016-02-20 0:26 ` Luke A. Guest 2016-02-20 6:28 ` tmoran 2 siblings, 0 replies; 30+ messages in thread From: Luke A. Guest @ 2016-02-20 0:26 UTC (permalink / raw) Randy Brukardt <randy@rrsoftware.com> wrote: > True thin bindings are trivial to make (and can be pretty much automated), > but they completely lose any advantage to using Ada. Pretty much the only > thing to do with a true thin-binding is use it to make a thicker binding, > else you would be better off writing in C. (C has meager correctness > checking, but you lose even that when you cross the boundary between > languages. The use of Ada is actually a negative in such circumstances.) Vulkan really is an unusual API in that there is supposed to be minimal to no error checking at the lowest layer. The higher layers do the checking then when you release the app you turn off the debugging layers. The vk.xml file already separates bit masks and enums properly. I think this is likely to be a medium binding tbh. Luke ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-19 22:28 ` Randy Brukardt 2016-02-19 23:32 ` Olivier Henley 2016-02-20 0:26 ` Luke A. Guest @ 2016-02-20 6:28 ` tmoran 2016-02-22 23:56 ` Randy Brukardt 2 siblings, 1 reply; 30+ messages in thread From: tmoran @ 2016-02-20 6:28 UTC (permalink / raw) >The important reason for having access to some low-level binding is so that >one can directly translate examples into Ada. The idea is that a medium >binding preserves that (one uses the same objects, same parameters [possibly >better typed], same subprogram calls), but makes those calls more sensible >Ada code, letting the compiler provide more help to the programmer.) As I recall, there were a lot of Windows calls that did not work as documented (or weren't documented completely). A thick binding like CLAW works around and thus hides such things. A mechanically produced binding wouldn't do that. For instance, I have a mechanically produced thin, and hand made thick, binding to the Google Earth API. Several years ago Google changed the meaning of some of the parameters to an important function. The thick binding can check the API version and do the right thing - the thin binding can't. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: thick bindings, was Re: Vulkan is here! 2016-02-20 6:28 ` tmoran @ 2016-02-22 23:56 ` Randy Brukardt 0 siblings, 0 replies; 30+ messages in thread From: Randy Brukardt @ 2016-02-22 23:56 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:na912e$cv0$1@gioia.aioe.org... > >The important reason for having access to some low-level binding is so > >that >>one can directly translate examples into Ada. The idea is that a medium >>binding preserves that (one uses the same objects, same parameters >>[possibly >>better typed], same subprogram calls), but makes those calls more sensible >>Ada code, letting the compiler provide more help to the programmer.) > > As I recall, there were a lot of Windows calls that did not work as > documented (or weren't documented completely). A thick binding like CLAW > works around and thus hides such things. A mechanically produced binding > wouldn't do that. True enough. In fairness to Microsoft, the state of their documentation in more recent years is a lot better than it was when we started creating CLAW. I recall being surprised on several occasions by reading about stuff that we had to figure out by trial-and-error. (Of course, that probably came about because of their anti-trust problems. One of the things they agreed to in the settlements was to fully document all APIs. The typical open source library probably doesn't have legal reasons for getting the documentation correct and complete. ;-) Randy. ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2016-02-22 23:56 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-17 15:37 Vulkan is here! olivier.henley 2016-02-17 20:31 ` Randy Brukardt 2016-02-17 22:37 ` Luke A. Guest 2016-02-17 23:26 ` olivier.henley 2016-02-17 22:37 ` Luke A. Guest 2016-02-17 23:56 ` olivier.henley 2016-02-18 0:20 ` Olivier Henley 2016-02-18 1:22 ` Luke A. Guest 2016-02-18 15:58 ` Olivier Henley 2016-02-18 18:32 ` Per Sandberg 2016-02-18 23:21 ` Simon Wright 2016-02-19 5:14 ` Per Sandberg 2016-02-19 6:53 ` Per Sandberg 2016-02-19 8:20 ` Simon Wright 2016-02-19 9:01 ` Per Sandberg 2016-02-19 12:05 ` Simon Wright 2016-02-19 13:14 ` G.B. 2016-02-19 4:21 ` thick bindings, was " tmoran 2016-02-19 13:07 ` Olivier Henley 2016-02-19 15:38 ` Alejandro R. Mosteo 2016-02-19 16:54 ` Lucretia 2016-02-19 17:28 ` Per Sandberg 2016-02-19 17:41 ` Lucretia 2016-02-19 18:02 ` Lucretia 2016-02-19 19:53 ` Per Sandberg 2016-02-19 22:28 ` Randy Brukardt 2016-02-19 23:32 ` Olivier Henley 2016-02-20 0:26 ` Luke A. Guest 2016-02-20 6:28 ` tmoran 2016-02-22 23:56 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox