Comments (21)
The style check warnings for the license header have been fixed in fbecae0.
from recordflux.
Hi Daly,
This is not a known problem. Typically, the compilation takes only a couple of seconds on a modern workstation, even for code generated from a complex specification. In the past, we have observed that certain compiler flags can negatively affect the compilation time, but the resulting compilation time was always still in the order of minutes, not hours.
Which toolchain are you using? Do you use specific compiler flags? Could you provide a small reproducer, where this issue can be observed?
from recordflux.
Thanks for the quick reply. It seemed off to me too - I expect a few seconds to a few minutes to build. I can put together a reproducer and send to you this week.
Here are the compiler flags I am running with at the moment (I use Alire
to manage my projects):
"-Og" -- Optimize for debug
,"-ffunction-sections" -- Separate ELF section for each function
,"-fdata-sections" -- Separate ELF section for each variable
,"-g" -- Generate debug info
,"-gnatwa" -- Enable all warnings
,"-gnatw.X" -- Disable warnings for No_Exception_Propagation
,"-gnatVa" -- All validity checks
,"-gnaty3" -- Specify indentation level of 3
,"-gnatya" -- Check attribute casing
,"-gnatyA" -- Use of array index numbers in array attributes
,"-gnatyB" -- Check Boolean operators
,"-gnatyb" -- Blanks not allowed at statement end
,"-gnatyc" -- Check comments
,"-gnaty-d" -- Disable check no DOS line terminators present
,"-gnatye" -- Check end/exit labels
,"-gnatyf" -- No form feeds or vertical tabs
,"-gnatyh" -- No horizontal tabs
,"-gnatyi" -- Check if-then layout
,"-gnatyI" -- check mode IN keywords
,"-gnatyk" -- Check keyword casing
,"-gnatyl" -- Check layout
,"-gnatym" -- Check maximum line length
,"-gnatyn" -- Check casing of entities in Standard
,"-gnatyO" -- Check that overriding subprograms are explicitly marked as such
,"-gnatyp" -- Check pragma casing
,"-gnatyr" -- Check identifier references casing
,"-gnatyS" -- Check no statements after THEN/ELSE
,"-gnatyt" -- Check token spacing
,"-gnatyu" -- Check unnecessary blank lines
,"-gnatyx" -- Check extra parentheses
,"-gnatX" -- Enable GNAT Extensions
I should mention I'm using a Debian based docker container run on a Mac M1 (so the Debian container is an arm64
architecture, running natively and not using Rosetta). This isn't an issue normally: I have great performance developing in Ada/SPARK with this setup. I should also mention that the issue is also reproduced in our pipeline: we use GitLab internally and even on their beefier amd64
shared runners it was taking 1 hour++ (and burning our CI minutes :( ).
I'm using the following version of gnat
:
GNAT 13.2.0
Copyright (C) 1996-2023, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm using the latest version of RecordFlux
from pypi
: 0.14.0
.
I'll make a reproducer that is a bit simpler than what I have but still demonstrates what is happening.
from recordflux.
Here is a very basic example: this reproducer will only take a couple of minutes to build for me, but it shows the issue starting to creep in. Maybe I am not using the generated code properly and that is the issue.
To really expose my issue, I can add in more conditionals on the transitions and more fields in the messages to really highlight it (and make it more similar to the real messages we are trying to model). I'll hold off on that if this reproducer is good enough.
Let me know, thanks!
from recordflux.
Thank you for the reproducer. A build time of a couple of minutes is much longer than we have seen with much more complicated specifications. We will investigate and let you know when we know more.
from recordflux.
Thanks!
And to be clear: I trimmed this down quite a bit from the real application we are building. The message structure is similar but larger and more complicated and building takes 1 hour++.
from recordflux.
The long compilation time is caused by the use of the -gnatX
flag. When the flag is removed, your reproducer builds in less than a second. It is unexpected that -gnatX
has such a severe impact and I have informed the compiler team about the problem. For now, the only workaround I can see is not to use -gnatX
.
from recordflux.
Ahhhh thanks! Doh! I should of tried that instead of trying a bunch of other flags.
from recordflux.
I should mention the same issue occurs with -gnat2022
, so it's not just the -gnatX
GNAT extensions.
from recordflux.
Also, to avoid creating another issue, I've had problems with some more compiler switches:
-
GNAT style checks fail. I tried to run the generated files through the pretty printer to fix some of them but the GNAT pretty printer crashes. I've raised an issue for that one: AdaCore/libadalang-tools#29. For now, I use
sed
to prependpragma Style_Checks (Off);
to every generated file. I'm using the Alirevalidation
profile to run these checks. -
-gnatwq
causes issues for some of the generated code. For example (from the reproducer):recordflux-build/generated/rflx-variant_two-data.adb:628:52: warning: equality should be parenthesized here [-gnatwq]
. -
-gnatw.a
causes issues in the generated code. For example (not from the reproducer but from my own specs):warning: in instantiation at rflx-rflx_message_sequence.ads:54 [-gnatw.a]
andwarning: check will fail at run time [-gnatw.a]
. The line it is pointing to is here:
procedure Initialize (Ctx : out Context; Buffer : in out RFLX_Types.Bytes_Ptr) with
Pre =>
(not Ctx'Constrained
and then Buffer /= null
and then Buffer'Length > 0
and then Buffer'Last < RFLX_Types.Index'Last),
Post =>
(Has_Buffer (Ctx)
and Valid (Ctx)
and Buffer = null
and Ctx.Buffer_First = Buffer'First'Old
and Ctx.Buffer_Last = Buffer'Last'Old
and Ctx.First = RFLX_Types.To_First_Bit_Index (Ctx.Buffer_First)
and Ctx.Last = RFLX_Types.To_Last_Bit_Index (Ctx.Buffer_Last)
and Sequence_Last (Ctx) = Ctx.First - 1),
Depends =>
(Ctx => Buffer, Buffer => null);
Cheers!
from recordflux.
- GNAT style checks fail. I tried to run the generated files through the pretty printer to fix some of them but the GNAT pretty printer crashes. I've raised an issue for that one: gnatpp crashes when setting -c3 to format commments and comment has no characters libadalang-tools#29. For now, I use
sed
to prependpragma Style_Checks (Off);
to every generated file. I'm using the Alirevalidation
profile to run these checks.
I already have seen some style check warnings in your reproducer. These warnings were caused by the use of -gnatyc
("Check comments, double space.") which enforces a different spacing than -gnatyC
("Check comments, single space.") that we use for our code. We already use pragma Style_Checks
to prevent such issues, but as this pragma is placed after the license header, GNAT still complains about the spacing there. We consider moving the pragma Style_Checks
to the top of the file to prevent this issue. Did you see any other style issues?
-gnatwq
causes issues for some of the generated code. For example (from the reproducer):recordflux-build/generated/rflx-variant_two-data.adb:628:52: warning: equality should be parenthesized here [-gnatwq]
.
I cannot reproduce the issue with RecordFlux 0.15.0. Please check if upgrading RecordFlux solves the issue for you.
-gnatw.a
causes issues in the generated code. For example (not from the reproducer but from my own specs):warning: in instantiation at rflx-rflx_message_sequence.ads:54 [-gnatw.a]
andwarning: check will fail at run time [-gnatw.a]
. The line it is pointing to is here:procedure Initialize (Ctx : out Context; Buffer : in out RFLX_Types.Bytes_Ptr) with Pre => (not Ctx'Constrained and then Buffer /= null and then Buffer'Length > 0 and then Buffer'Last < RFLX_Types.Index'Last), Post => (Has_Buffer (Ctx) and Valid (Ctx) and Buffer = null and Ctx.Buffer_First = Buffer'First'Old and Ctx.Buffer_Last = Buffer'Last'Old and Ctx.First = RFLX_Types.To_First_Bit_Index (Ctx.Buffer_First) and Ctx.Last = RFLX_Types.To_Last_Bit_Index (Ctx.Buffer_Last) and Sequence_Last (Ctx) = Ctx.First - 1), Depends => (Ctx => Buffer, Buffer => null);
I have seen this warning when using -gnatVo
. The only workaround I know is to not enable this switch. The bug does not exist in recent GNAT Pro releases. Only the FSF GNAT 13 seems to be affected, so it could make sense to report the issue to the FSF.
from recordflux.
Awesome - thanks for the response! We are using 0.14.0
version of RecordFlux so I'll update today and check again. Cheers!
from recordflux.
After updating to 0.15.0
I can confirm that the -gnatwq
has been addressed and the -gnatw.a
seems to have also gone away. (The installation issue I had raised in another issue is also fixed!).
Thanks for everything!
from recordflux.
You are welcome! I'm glad to hear that most of your issues have been resolved in the new version. We will probably also fix the style check problem soon.
from recordflux.
The long compilation time is caused by the use of the
-gnatX
flag. When the flag is removed, your reproducer builds in less than a second. It is unexpected that-gnatX
has such a severe impact and I have informed the compiler team about the problem. For now, the only workaround I can see is not to use-gnatX
.
Has any progress been made here? It's not just -gnatX
: it's any Ada2022 flag. I don't have a good workaround at the moment for code written to use Ada2022 to also make use of RecordFlux ... I just can't build it at all. Thanks!
from recordflux.
The fix is currently in progress. Unfortunately, it appears to be a difficult problem and it is not yet clear how long it will take to complete.
As a workaround you could try to set the -gnatX
or -gnat2022
flag on a per-file basis in the project file, but this will only help for files that don't use RecordFlux directly.
from recordflux.
The fix is currently in progress. Unfortunately, it appears to be a difficult problem and it is not yet clear how long it will take to complete.
As a workaround you could try to set the
-gnatX
or-gnat2022
flag on a per-file basis in the project file, but this will only help for files that don't use RecordFlux directly.
Thanks for the response! And glad to hear it is in progress :). I'll try your suggestion, I wasn't sure how to mix and match the two to be honest. The combinations I had tried so far weren't working as I expected. I'll try out your suggestion! The alternative which I think will work is to build my RecordFlux project as a separate library and link it.
from recordflux.
So adding pragma Ada_2012
to all the generated code solves the problem! I think that would be a good thing to include automatically as part of the rflx generate
command so that others don't run into the issue. It is true either way that the code doesn't compile with Ada2022+ so probably a nice informative thing to put for now!
from recordflux.
So adding
pragma Ada_2012
to all the generated code solves the problem! I think that would be a good thing to include automatically as part of therflx generate
command so that others don't run into the issue. It is true either way that the code doesn't compile with Ada2022+ so probably a nice informative thing to put for now!
Great to hear and thanks for reporting back! Adding that pragma to the generated code should be easy to do. I created an internal ticket for that.
from recordflux.
@dalybrown This is to let you know that pragma Ada_2012
is now automatically added to all generated files. That change is on main
and will be part of the next public release.
from recordflux.
Awesome - thanks!
from recordflux.
Related Issues (20)
- Documentation for released versions HOT 1
- Enable DHCP client tests without Docker
- Use `why3server` HOT 3
- Add missing quotes to error message about invalid aspects HOT 1
- Style error leads to parser and model errors HOT 1
- Release 0.8.0 HOT 1
- Allow updating of generated files HOT 1
- Invalid "always true" error for enum with `Always_Valid` aspect HOT 1
- Release 0.9.0 HOT 1
- C code generator
- Refactoring of expressions HOT 4
- Problems trying to specify HDLC HOT 1
- Allow setting the GNATCOLL_ICONV_OPT environment variable when installing RecordFlux HOT 1
- Mathematical expression for first and last of integer types does not support parentheses to ensure the order of operations HOT 2
- Bug when including a condition on a field that is a message type HOT 4
- Allow setting the GNATCOLL_ICONV_OPT environment variable in Makefile HOT 9
- Bug when comparing opaque values HOT 2
- Command line switch `rflx --no-verification --unsafe generate` doesn't seem to work HOT 3
- Missing `alr build` step either in instructions or in Makefile HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from recordflux.