Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Thanks Jean-Pierre for the idea, Nevertheless, I propose to postpone all these sort of changes (breaking interface and so on) to version 2.0. Regards, Pascal. http://blady.pagesperso-orange.fr > Le 31 janv. 2017 à 10:09, Jean-Pierre Rosen a écrit : > > Le 30/01/2017 à 21:47, Pascal a écrit : >> Changing them will clearly introduce backward compatibility issues. >> Is it worth refactoring all of them or a part of them? >> > Note: you can make the change using AdaSubst and the appropriate > dictionary. The dictionary can be given to users, so they can make the > change automatically and without risk. > > -- > 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 > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Hello David, I ran gnat pretty printer on Gnoga code. There are many minor corrections of mainly indentations. There are also few changes: 1) is place: - procedure Finalize - is + procedure Finalize is 2) record place: - type Storage_Type is tagged - record - Connection_ID : Gnoga.Types.Connection_ID := - Gnoga.Types.No_Connection; - end record; + type Storage_Type is tagged record + Connection_ID : Gnoga.Types.Connection_ID := Gnoga.Types.No_Connection; + end record; 3) parameters place: - function Connection_ID (Object : Base_Type) - return Gnoga.Types.Connection_ID + function Connection_ID + (Object : Base_Type) + return Gnoga.Types.Connection_ID Is it ok like that? Thanks, Pascal. http://blady.pagesperso-orange.fr > Le 11 nov. 2016 à 12:02, Pascal a écrit : > > Hello, > > Gnoga coding guidelines proposal and an extract of mailing list comments (as > discussion paragraphs) have been gathered on : > > https://sourceforge.net/p/gnoga/wiki/Coding-Guidelines/ > > Any comments are welcome either on coding rules topics or Markdown text (as > I'm newbee). > > David feel free to put your final status on topics under discussion. > > Regards, Pascal. > http://blady.pagesperso-orange.fr > > > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. http://sdm.link/xeonphi > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Le 12/11/2016 à 19:17, Pascal a écrit : > Amazing result with just a dozen of rules :-) I often say that my clients hate me - when they discover the number of violations that passed through their careful hand reviews... > Few comments on result: > > - gnoga-types-colors.adb:10:1: Error: HEADER_COMMENTS: line does not match > pattern "^-- Copyright \(C\) 2014 David Botton > --$" > In the header, the year and author name should be any value The year is "20"+2digits. I agree that the pattern sould be made a bit more tolerant... Since it is a full regexp, it's easy to adjust it. > - gnoga-types-colors.adb:47:7: Error: NAMING_CONVENTION: Name does not follow > naming rule for "all": "aliceblue" > Enumeration names should not follow type rule. It's not the type rule, it's just that I require all identifiers to be capitalized. > - Is it possible to check "_Type" suffix only for record or tagged record > type? Of course. You can have naming conventions for pretty much any form of declaration. > What is the command line for adacontrol? Well, if you download AdaControl, it comes with a pretty extensive user guide... In its simplest form: adactl -f gnoga.aru *.ads *.adb -- 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 -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Hello Jean-Pierre, Amazing result with just a dozen of rules :-) Few comments on result: - gnoga-types-colors.adb:10:1: Error: HEADER_COMMENTS: line does not match pattern "^-- Copyright \(C\) 2014 David Botton --$" In the header, the year and author name should be any value - gnoga-types-colors.adb:47:7: Error: NAMING_CONVENTION: Name does not follow naming rule for "all": "aliceblue" Enumeration names should not follow type rule. - Is it possible to check "_Type" suffix only for record or tagged record type? What is the command line for adacontrol? Thanks, Pascal. http://blady.pagesperso-orange.fr > Le 12 nov. 2016 à 17:39, Jean-Pierre Rosen a écrit : > > Le 11/11/2016 à 12:02, Pascal a écrit : >> Hello, >> >> Gnoga coding guidelines proposal and an extract of mailing list >> comments (as discussion paragraphs) have been gathered on : >> >> https://sourceforge.net/p/gnoga/wiki/Coding-Guidelines/ > Just for the fun of it, I translated these guidelines into AdaControl. > > Attached is the rules file (with associated header comment file), and > the result of running it; 345 violations is not that bad for a first > automatic checking ;-) > > Looking at the violations is also a good mean of refining the rules... > > > -- > 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 > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. > http://sdm.link/xeonphi___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Thanks, Jeff, fix in SF Gnoga wiki. > Le 11 nov. 2016 à 17:37, Jeffrey R. Carter a écrit : > > On 11/11/2016 04:02 AM, Pascal wrote: >> Any comments are welcome either on coding rules topics or Markdown text (as >> I'm newbee). >> > Some proofreading: > > • Section 7 occurs twice > • Section 8: "it's" should be "its" > • Section 13: "platform" is misspelled in the header > -- > Jeff Carter > "Drown in a vat of whiskey. Death, where is thy sting?" > Never Give a Sucker an Even Break > 106 > > -- > Developer Access Program for Intel Xeon Phi Processors > Access to Intel Xeon Phi processor-based developer platforms. > With one year of Intel Parallel Studio XE. > Training and support from Colfax. > Order your platform today. > http://sdm.link/xeonphi___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list -- Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On 2016-10-20 09:24, Jean-Pierre Rosen wrote: > Le 19/10/2016 à 23:22, David Botton a écrit : >> > I would add that in all cases Gnoga must compile and work with the FSF >> > GNAT versions readily available for Windows, Mac, Linux and BSDs. The >> > reason I add this is that in no way should Gnoga ever be dependant on >> > GPL GNAT features not available in the true free versions. > I agree, but I am surprised by this statement. What are the features in > GPL that are not available in FSF? > Over the years, I have tried to compile our system with different FSF GNATs. The only one that did compile ALL our code is the GNAT-AUX on Freebsd (I tried it 5-6 years ago). All other FSF have choked on some task construct or arrays of Limited_Controlled types containing access to other Limited_Controlled types. I never quite understood it well enough to create a simple reproducible test case :-( GNAT Pro works and so does GNAT GPL ( on 32/64 Linux since 2012) FSF 4.9.2 does not -- Björn -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Hello David, > Le 21 oct. 2016 à 05:47, David Botton a écrit : > > Well if someone is inspired that upgrade is doable. > > Most unrestricted access is just used in creating simple examples not in the > framework. I'll add that guidelines apply only on the Gnoga framework (that is not mandatory on demo, tuto and tests but it is encouraged). > > Since Ada is effectively dead outside of GNAT for future development, in my > mind only supporting FSF GNAT is important as it will always be a subset of > GPL GNAT and GNAT PRO and the reasons I freely wrote it to depend on GNAT > from the start. That's why the proposed wording is "must be independent" on interface (Ada spec) and "should be independent" on implementation (Ada body). If one day one compiler other than GNAT want to offer a Gnoga implementation then it will be able to. Let's be optimistic, actually Ada 2005 was not enough attractive but Ada 2012 brings real interests in industry. Among them, contract programming reduce "defensive design" and catch bugs earlier than later that is more cost consuming, as we know. "The demand builds supply" (my poor translation of "la demande crée l'offre") ;-) > > David Botton -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Well if someone is inspired that upgrade is doable. Most unrestricted access is just used in creating simple examples not in the framework. Since Ada is effectively dead outside of GNAT for future development, in my mind only supporting FSF GNAT is important as it will always be a subset of GPL GNAT and GNAT PRO and the reasons I freely wrote it to depend on GNAT from the start. David Botton On Thu, Oct 20, 2016 at 11:40 PM Weston Pan wrote: > Hi > > I find it odd to ask for compiler independence at this point. When last I > looked at Gnoga it depends on GNAT specific libraries and attributes (eg > Unrestricted_Access). Unless, do you really mean not specific to either FSF > or GNAT GPL? > > > On Wednesday, October 19, 2016, Pascal wrote: > > Many thanks for all contributions. > > I'd like to add two points: > > Compiler: > Interface shall not be compiler dependent and implementation should not be > compiler dependent. > > Language: > The Ada language standard used is Ada 2012 without restrictions. > > PS : as one may have understood, these Gnoga guidelines are as closed from > existing source code but all is open for suggestions, IMHO. For sure, the > aim is to set a "Gnoga style" for futures code contributions. > > Go on sending comments, Pascal. > http://blady.pagesperso-orange.fr > > > > Le 19 oct. 2016 à 00:19, Anh (TA) Vo a écrit : > > > > On Sun, Oct 16, 2016 at 10:25 PM, Jean-Pierre Rosen > wrote: > > Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : > > >> I'm OK for disabling assertions, but not other checks > (constraint_error...) > > > I'm for leaving them all on. > > When I said "assertions", I meant all forms of assertions (including > > Pre/Post), not just pragma Assert. > > > > The trouble is that sometimes, the post-condition needs more > > computations than the subprogram being described. > > > > But it should be shorter that unit test :-). Post conditions replacing > unit test is my most favorite feature. > > > > Anh Vo > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! > http://sdm.link/slashdot___ > > Gnoga-list mailing list > > Gnoga-list@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gnoga-list > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > > > > -- > -- Weston > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Hi I find it odd to ask for compiler independence at this point. When last I looked at Gnoga it depends on GNAT specific libraries and attributes (eg Unrestricted_Access). Unless, do you really mean not specific to either FSF or GNAT GPL? On Wednesday, October 19, 2016, Pascal wrote: > Many thanks for all contributions. > > I'd like to add two points: > > Compiler: > Interface shall not be compiler dependent and implementation should not be > compiler dependent. > > Language: > The Ada language standard used is Ada 2012 without restrictions. > > PS : as one may have understood, these Gnoga guidelines are as closed from > existing source code but all is open for suggestions, IMHO. For sure, the > aim is to set a "Gnoga style" for futures code contributions. > > Go on sending comments, Pascal. > http://blady.pagesperso-orange.fr > > > > Le 19 oct. 2016 à 00:19, Anh (TA) Vo > a écrit : > > > > On Sun, Oct 16, 2016 at 10:25 PM, Jean-Pierre Rosen > wrote: > > Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : > > >> I'm OK for disabling assertions, but not other checks > (constraint_error...) > > > I'm for leaving them all on. > > When I said "assertions", I meant all forms of assertions (including > > Pre/Post), not just pragma Assert. > > > > The trouble is that sometimes, the post-condition needs more > > computations than the subprogram being described. > > > > But it should be shorter that unit test :-). Post conditions replacing > unit test is my most favorite feature. > > > > Anh Vo > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot__ > _ > > Gnoga-list mailing list > > Gnoga-list@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gnoga-list > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- -- Weston -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
In the past there have been language feature differences. One large reason for dropping AWS is that at one point it wouldn't compile on most FSF GNAT versions. It does compile currently on TDM and others but there are no gprtools. I did build gnoga originally to compensate and also showed how to use the 32 bit tools with some pain. It would be good to have a full GNAT for Windows 64 distribution comparable to others. David Botton On Thu, Oct 20, 2016, 3:24 AM Jean-Pierre Rosen wrote: > Le 19/10/2016 à 23:22, David Botton a écrit : > > I would add that in all cases Gnoga must compile and work with the FSF > > GNAT versions readily available for Windows, Mac, Linux and BSDs. The > > reason I add this is that in no way should Gnoga ever be dependant on > > GPL GNAT features not available in the true free versions. > I agree, but I am surprised by this statement. What are the features in > GPL that are not available in FSF? > > > On a related note, I would be particularly thrilled if we partnered up > > with Simon for an official public Mac build (which by default we are > > doing anyways) and if someone was willing to officially support a > > windows 64 bit build they would be doing a favor to the entire world > > since currently workarounds are need to use just about everything > > publicly available (AdaCore is particular on not releasing win 64 > > versions to the public) > > > I used out-of-the-box Gnoga on a Win64 box without problems. Is it > necessary to have a different version? > > -- > 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 > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Le 19/10/2016 à 23:22, David Botton a écrit : > I would add that in all cases Gnoga must compile and work with the FSF > GNAT versions readily available for Windows, Mac, Linux and BSDs. The > reason I add this is that in no way should Gnoga ever be dependant on > GPL GNAT features not available in the true free versions. I agree, but I am surprised by this statement. What are the features in GPL that are not available in FSF? > On a related note, I would be particularly thrilled if we partnered up > with Simon for an official public Mac build (which by default we are > doing anyways) and if someone was willing to officially support a > windows 64 bit build they would be doing a favor to the entire world > since currently workarounds are need to use just about everything > publicly available (AdaCore is particular on not releasing win 64 > versions to the public) > I used out-of-the-box Gnoga on a Win64 box without problems. Is it necessary to have a different version? -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
I would add that in all cases Gnoga must compile and work with the FSF GNAT versions readily available for Windows, Mac, Linux and BSDs. The reason I add this is that in no way should Gnoga ever be dependant on GPL GNAT features not available in the true free versions. On a related note, I would be particularly thrilled if we partnered up with Simon for an official public Mac build (which by default we are doing anyways) and if someone was willing to officially support a windows 64 bit build they would be doing a favor to the entire world since currently workarounds are need to use just about everything publicly available (AdaCore is particular on not releasing win 64 versions to the public) David Botton On Wed, Oct 19, 2016 at 4:20 PM Pascal wrote: > Many thanks for all contributions. > > I'd like to add two points: > > Compiler: > Interface shall not be compiler dependent and implementation should not be > compiler dependent. > > Language: > The Ada language standard used is Ada 2012 without restrictions. > > PS : as one may have understood, these Gnoga guidelines are as closed from > existing source code but all is open for suggestions, IMHO. For sure, the > aim is to set a "Gnoga style" for futures code contributions. > > Go on sending comments, Pascal. > http://blady.pagesperso-orange.fr > > > > Le 19 oct. 2016 à 00:19, Anh (TA) Vo a écrit : > > > > On Sun, Oct 16, 2016 at 10:25 PM, Jean-Pierre Rosen > wrote: > > Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : > > >> I'm OK for disabling assertions, but not other checks > (constraint_error...) > > > I'm for leaving them all on. > > When I said "assertions", I meant all forms of assertions (including > > Pre/Post), not just pragma Assert. > > > > The trouble is that sometimes, the post-condition needs more > > computations than the subprogram being described. > > > > But it should be shorter that unit test :-). Post conditions replacing > unit test is my most favorite feature. > > > > Anh Vo > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, SlashDot.org! > http://sdm.link/slashdot___ > > Gnoga-list mailing list > > Gnoga-list@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gnoga-list > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > ___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list > -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Many thanks for all contributions. I'd like to add two points: Compiler: Interface shall not be compiler dependent and implementation should not be compiler dependent. Language: The Ada language standard used is Ada 2012 without restrictions. PS : as one may have understood, these Gnoga guidelines are as closed from existing source code but all is open for suggestions, IMHO. For sure, the aim is to set a "Gnoga style" for futures code contributions. Go on sending comments, Pascal. http://blady.pagesperso-orange.fr > Le 19 oct. 2016 à 00:19, Anh (TA) Vo a écrit : > > On Sun, Oct 16, 2016 at 10:25 PM, Jean-Pierre Rosen wrote: > Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : > >> I'm OK for disabling assertions, but not other checks (constraint_error...) > > I'm for leaving them all on. > When I said "assertions", I meant all forms of assertions (including > Pre/Post), not just pragma Assert. > > The trouble is that sometimes, the post-condition needs more > computations than the subprogram being described. > > But it should be shorter that unit test :-). Post conditions replacing unit > test is my most favorite feature. > > Anh Vo > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! > http://sdm.link/slashdot___ > Gnoga-list mailing list > Gnoga-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gnoga-list -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On Sun, Oct 16, 2016 at 10:25 PM, Jean-Pierre Rosen wrote: > Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : > >> I'm OK for disabling assertions, but not other checks > (constraint_error...) > > I'm for leaving them all on. > When I said "assertions", I meant all forms of assertions (including > Pre/Post), not just pragma Assert. > > The trouble is that sometimes, the post-condition needs more > computations than the subprogram being described. > > But it should be shorter that unit test :-). Post conditions replacing > unit test is my most favorite feature. > Anh Vo -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Le 17/10/2016 à 22:56, Jeffrey R. Carter a écrit : > While you will get no argument from me, I think it fair to point out that the > guidelines have to fit with the existing Gnoga code by Botton, which uses such > redundant suffices extensively. > Agreed. We are not starting a new project here, just making sure that contributors keep a standard style. IMHO, I do not fully agree with all these rules, however, whatever the rules, the important issue is to keep a uniform style. -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On 10/17/2016 07:54 AM, marci...@earthlink.net wrote: > Ugh :( While you will get no argument from me, I think it fair to point out that the guidelines have to fit with the existing Gnoga code by Botton, which uses such redundant suffices extensively. -- Jeff Carter "When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada!" Robert Dewar 62 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
-Original Message- >From: Pascal >Sent: Oct 15, 2016 5:06 AM >To: Gnoga support list >Subject: [Gnoga-list] Proposal for Gnoga coding guidelines. > ... > Ada type entity is ending with "_Type" for a common type, > "_Access" for an simple > access type, "_Class" for an access to class type. > Example: ... Ugh :( Why not: "If you choose to append such a "language construct" marker to type names then they must be as you stated. That way such a marker is not mandated. Reason to not mandate such markers: - why not also "_protected", "_task", "_private" etc.? Wouldn't they be just as "helpful". I think that this kind of "style" rule was really only necessarily helpful in languages like C that did not have a strong type system. -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On 10/16/2016 10:25 PM, Jean-Pierre Rosen wrote: > When I said "assertions", I meant all forms of assertions (including > Pre/Post), not just pragma Assert. > > The trouble is that sometimes, the post-condition needs more > computations than the subprogram being described. Such conditions should probably be described as comments, so that computationally reasonable conditions can still be checked. -- Jeff Carter "There's no messiah here. There's a mess all right, but no messiah." Monty Python's Life of Brian 84 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Le 16/10/2016 à 19:54, Jeffrey R. Carter a écrit : >> I'm OK for disabling assertions, but not other checks (constraint_error...) > I'm for leaving them all on. When I said "assertions", I meant all forms of assertions (including Pre/Post), not just pragma Assert. The trouble is that sometimes, the post-condition needs more computations than the subprogram being described. -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On 10/16/2016 08:10 AM, Jean-Pierre Rosen wrote: > Le 15/10/2016 à 11:06, Pascal a écrit : >> Functions and procedures must be declared before coding the body. > Not sure it is very useful. I don't have a rule for this in Adacontrol, > but it could be easily added. It seems a reasonable language-design principle that every body should be the completion of a separate specification. Ada seems to follow this except for subprograms. Alternatively, given the rule that descriptive comments follow the thing being described, and since descriptive comments after a subprogram body are useless, comments describing a subprogram should come after a declaration. Since every subprogram should have descriptive comments ... > I'm OK for disabling assertions, but not other checks (constraint_error...) I'm for leaving them all on. -- Jeff Carter "There's no messiah here. There's a mess all right, but no messiah." Monty Python's Life of Brian 84 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
On 10/15/2016 02:06 AM, Pascal wrote: > Version numbering: > m.n with m major version number , n minor version number. > -alpha is added on m.n when this version is created, to be used without any > warranty. > -beta is added on m.n when this version is enough mature to be tested. > Then a letter is added on m.n when this version becomes a stable reference > release (fully tested). > The letter is incremented when fixes come. > For instance : 1.2-alpha, 1.2-beta, 1.2a, 1.2b, 1.2c… We've discussed this already. I still feel there should be a role for m.n without any suffix. > Getter and setter names are identical as Ada provides function for getters > and procedure for setters. This is current Gnoga style, but I find it awkward. Standard usage is for procedure names to be verbs or verb phrases. Non-Boolean functions should be nouns or noun phrases; Boolean functions should be adjectives, adjective phrases, or predicates. > Ada type entity is ending with "_Type" for a common type, "_Access" for an > simple access type, "_Class" for an access to class type. It seems to be a rule about coding guides that everyone likes some part of the guidelines, but no one likes all of them. I guess I'll have to retract the Plotting pkg, since I have (sub)types named Plot_Info, Plot_Point, Positive_Float, and Point_List, but none that end with these suffices. > Implementation must target Linux, macOS and Windows platform. Since Gnoga targets browsers, not platforms, shouldn't this be a list of browsers rather than OSes? -- Jeff Carter "There's no messiah here. There's a mess all right, but no messiah." Monty Python's Life of Brian 84 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
Re: [Gnoga-list] Proposal for Gnoga coding guidelines.
Le 15/10/2016 à 11:06, Pascal a écrit : > Here is a proposal for Gnoga coding guidelines: > > Version numbering: m.n with m major version number , n minor version > number. -alpha is added on m.n when this version is created, to be > used without any warranty. -beta is added on m.n when this version > is enough mature to be tested. Then a letter is added on m.n when > this version becomes a stable reference release (fully tested). The > letter is incremented when fixes come. For instance : 1.2-alpha, > 1.2-beta, 1.2a, 1.2b, 1.2c… OK For the rest, I volunteer to provide an AdaControl rules file to enforce the guidelines. > Header: Several lines of fixed comments customized with the name of > the unit, the creation date and the name of the author. Needs a template, can be checked by AdaControl > Purpose of the unit: Several line of comments indicating the purpose > of the unit after header and before first declaration. Uncheckable > Coding style: Line length is limited to 120 characters. Ada keyword > are in lower case. Ada entities are in mixed case with an underscore > to separate words. All checkable > Getter and setter names are identical as Ada provides function for > getters and procedure for setters. This is current practice in Gnoga, however I'm not so much in favour of it, because it prevents the usual usage that functions names are names or adjectives, while procedure names are verbs. Presumably too late to change for Gnoga. I would be interested in having a more formal definition of this rule (i.e. what could be checked here?). Maybe an opportunity to add something to AdaControl. > Entity description is lines of comments below the entity declaration. > Gnatdoc annotations are recommended, see > http://docs.adacore.com/gnatdoc-docs/users_guide/_build/html/gnatdoc.html#annotating-source-files. OK > > > Ada contracts Pre, Post and type invariant are recommended. OK, but not checkable as long as it is "recommended" and not "required" > Ada type entity is ending with "_Type" for a common type, "_Access" > for an simple access type, "_Class" for an access to class type. OK, checkable > > Functions and procedures must be declared before coding the body. Not sure it is very useful. I don't have a rule for this in Adacontrol, but it could be easily added. > > Use clause is restricted to minimum use, preferably local use to > functions or procedures. Use type clause is recommended. Checkable > Code reformat is recommended before commit to Gnoga repository. Not really checkable... > Syntax check is mandatory before commit to Gnoga repository. I'd rather say that every commit must compile! (not only syntax checks) > For debug builds, most warnings, runtime verifications and exception > tracebacks are recommended. (including enabling all assertions) > > For release builds, runtime verifications disabled and optimisations > enabled are recommended. I'm OK for disabling assertions, but not other checks (constraint_error...) -- 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
