Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mark not matching bytes red in received packet #115

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

fridolinsiegmund
Copy link

Hi,
it would be great to determine which bytes exactly are not matching between the received and expected packet with "graphical support", therefore i propose this solution where the not matching bytes at the received packet are marked red.

@fridolinsiegmund
Copy link
Author

Hi @antoninbas and @jafingerhut ,
I updated my PTF fork to the most recent commit in the main branch in this repository.
Any updates on my pull request? I still think having the wrong bytes marked red helps debugging.

Best Wishes,
Fridolin

@jafingerhut
Copy link
Collaborator

I have not tried out your changes yet, but do they insert the terminal escape sequences that change color on some kinds of virtual terminals unconditionally? That is, if I were to run PTF in batch mode with output saved in a text file, would the escape sequences be inserted there, too?

Having some kind of command line option to enable/disable the insertion of these escape sequences seems better to me than enabling them unconditionally. I'm not sure what the default should be.

I believe Linux commands like ls often somehow automatically determine whether their output is to a terminal or not at run time, and insert colorization when their output to a terminal, but do not insert colorization when their output is to a file or pipe. That seems preferable to me.

@jafingerhut
Copy link
Collaborator

I have attempted to send an email to the address [email protected], but I got back an error message containing this text. Fun! :-)

Address not found
Your message wasn't delivered to [email protected] because the address couldn't be found, or is unable to receive mail.
The response from the remote server was:550 #5.1.0 Address rejected.

@antoninbas
Copy link
Member

@jafingerhut if you can't get a hold of anyone at Intel, I think it is possible to block the bot account at the p4lang-org level, so that it can no longer comment.

@jafingerhut
Copy link
Collaborator

@antoninbas Good to know, in case that turns out to be useful. There are a couple of people within Intel looking into this starting yesterday or today -- hopefully they can see what they can do at their end.

@grg
Copy link

grg commented Jul 24, 2024

@antoninbas @jafingerhut Intel is working to address this. The comments on the open-source repos were unintentional: there working on adjusting tools to only comment on internal repos, not the p4lang open-source ones.

They also plan to have someone delete the unintentional comments from the p4lang repos.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants