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

[feature] Throw error if a connector has duplicate entries in the pinnumbers list #72

Closed
formatc1702 opened this issue Jul 9, 2020 · 6 comments
Milestone

Comments

@formatc1702
Copy link
Collaborator

#10 allows the user to specify custom pin numbering schemes instead of auto-assigning pins 1 through N.

A check should be performed whether any pin number is assigned twice, and throw an error if so.

This is different from #71, since pin names need only be checked for duplicates if actually attempting to connect a pin with an ambiguous name, whereas pin numbers should be unique by definition, so this check should be performed during connector creation.

@kvid
Copy link
Collaborator

kvid commented Jul 9, 2020

Do you also check for any collision with s - the shield identifier? See my earlier comment in #10 (comment)

@formatc1702
Copy link
Collaborator Author

Thanks for reminding me, I never replied to that comment.
It is not an issue, since we are talking about connector pins/ports, whereas the s identifier is a cable's port. The GraphViz format for linking to a specific port inside a node is node_name:port_name so there won't be any confusion.

@kvid
Copy link
Collaborator

kvid commented Jul 9, 2020

OK, I thought these consepts applied to both cables and connectors. There exist connectors with shield that is not included in the pin numbering. And why not support custom wire identifiers also for completeness or to generalize the 'syntax? These are just my thoughts. I have no real need for any of it at the moment.

@formatc1702
Copy link
Collaborator Author

formatc1702 commented Jul 9, 2020

There exist connectors with shield that is not included in the pin numbering.

Yes, but right now, only cables have a dedicated shield: true property, which auto-generates a pseudo-wire labeled s. In the future, we will have to think about restructuring shields, to support more complex schemes such as multiple shields, nested shields, etc.
For connectors, you can manually add a "pin" labeled s, shield, or whatever you like.

And why not support custom wire identifiers also for completeness or to generalize the 'syntax?

Indeed, I also want to add a wirenames property to cables/bundles, and also make it possible to link to a specific wire color, as long as it's unambiguous.

@kvid
Copy link
Collaborator

kvid commented Jul 10, 2020

I'm sorry for all my comments about issues that don't apply. I don't have full knowledge about the source, and make wrong assumptions now and then. I'm impressed that you take the time to answer most comments this quickly.

@formatc1702
Copy link
Collaborator Author

I'm really thankful for the open discussions, improvement suggestions and code reviews!
If I didn't want that, I'd take the project off GitHub ;)

I want to follow through with as many features and bugfixes as possible now that momentum -both on my side and in the contributors- is high, and I can afford to put my time into the project :)

@formatc1702 formatc1702 added this to the v0.2 milestone Jul 19, 2020
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

No branches or pull requests

2 participants