Closed danielhollas closed 1 year ago
@danielhollas any help would be appreciated :)
@danielhollas Thanks a lot for taking this on, please let us know if you need any help with this.
This is now fixed.
When testing the SMILES widget I discovered that the error is back. @danielhollas can you please have a look?
When testing the SMILES widget I discovered that the error is back
Which SMILES specifically triggered the error? Is it the exact same stack trace?
Indeed, the original SMILES in this issue still throws an error, though it is a somewhat of a special case, which might be considered a bug in RDKit rather than here. Most invalid SMILES should be handled.
@yakutovicha did you see this with other smiles?
I tried some examples from the link. They all worked except for N#N
wich is gracefully handled:
n_components=3 must be between 0 and min(n_samples, n_features)=2 with svd_solver='full'
I also introduced some random errors in SMILES, and things seem to work there. But I cannot guarantee I tested all possible issues.
which might be considered a bug in RDKit rather than here
I still believe we need to handle that.
They all worked except for N#N wich is gracefully handled:
This is for sure a bug, could you open a new issue for this? It's not really about SMILES parsing, but the postprocessing code that orients the molecule does not handle 2-atom molecules.
I still believe we need to handle that.
Sure, but I do not think it blocks the 2.0 release.
The problem with N#N
has been fixed in #477
For example, this input:
CC(C)(C)*OO
generates this stack trace.Happy to take this on, but if anybody want to fix this go ahead. :-)