Tonight, before I start modifying the calc.p4 in the calculator exercise, I run the make command first, then a compilation error occurred as following.
But all my exercises before calc had no compilation errors and worked fine, so I guess there should be no problem with my environment. How should I solve this compilation error?
The errors in the picture seem to be due to the p4 code being incomplete / has errors.
Have you tried replacing the file in the main directory with the one in the solution folder?
Many of the exercises have partial implementations that give no compilation errors, but it would not surprise me if a few of them give compilation errors with the starting files. The README for each exercise will usually mention this, and suggest what you need to change to complete the exercise. As mentioned by another person responding, the solution directory contains complete working solutions in case you get stuck, or want to compare your solution to someone else’s.
I’m guessing what caused the problem. Could you tell me what does Message type “p4.config.v1.Table” has no field named “has_initial_entries” mean? It looks like this error occurs between step 1: - Using P4Info file build/calc.p4.p4info.txt… and step 2: - Connecting to P4Runtime server on 127.0.0.1:50051 (bmv2)…, but I’m not sure if step 1 is completed. Could you give me some advice to locate this bug? If it’s too hard for a beginner, what could I do is only skip the compilation step.
Which version of P4Runtime are you using? has_initial_entries was added recently but the compiler does not have support for it yet.
PR that adds it: https://github.com/p4lang/p4runtime/pull/432
fruffy this sounds like it might be an issue where the compiler is generating the new has_initial_entries field in P4Info file, but some other software attempting to read it is giving an error when it reads the P4Info file, probably some Python code in the tutorials repo.
If that is the case, it should be easy for me to reproduce and see if there is a fix that can be made in the tutorials repo code that causes it to ignore fields it does not recognize, vs. throwing an exception, which I recall making to some other Python code elsewhere in p4lang repos around the time that this PR was merged: https://github.com/p4lang/p4runtime/pull/432
but I did not see the errors that you did. I only tried it on the latest images published, that were built from the latest source code as of 2024-Jan-01, not older ones.
I encountered the exact same problem today. When running the calc solution from scratch, I filled in the s1-runtime.json tables. It seems that the build/*.p4.p4info.txt has a has_initial_entries: true field in tables. I installed the P4 environment on a Linux VM with install-p4dev-v6.sh script in the p4-guide repo.
Thanks for that clue to this issue. It seems to be that the install-p4dev-v6.sh vs. install-p4dev-v7.sh install scripts lead to different behavior here, probably because they install different versions of the protobuf library (at least that is my current best guess, before investigating in detail). I will see if I can get to the bottom of the root cause here.
In the mean time, as far as I know, the install-p4dev-v7.sh script is superior in most ways to the install-p4dev-v6.sh script, as long as you realize that you need to do source p4setup.bash after using it, every time you start a new shell (or put it in your ~/.bashrc file or equivalent for a different command shell if you do not use bash).
I have confirmed that the difference in behavior is due to different versions of the Protobuf library being installed. I don’t know exactly what changed between those two versions of the Protobuf library, but it is behaving differently in a “_MergeField” call being made as a result of the tutorials Python code calling a Merge method.
My recommendation stands that one prefer to use the install-p4dev-v7.sh script.
I would expect a system to end up in an unusable state if you attempted to run the v6 install script, then later the v7 install script, on the same system, or in the opposite order. I only test them starting from freshly installed Ubuntu or Fedora Linux systems, not with lots of related software already installed on them.
I do not know any faster way than starting from a freshly installed system, and running the v7 script.
