No edit summary |
(Adding categories) |
||
Line 48: | Line 48: | ||
All I/O modules in the toolkit have the capability to re-sync the file (trivial for SMILES, not so simple for SDF). In the read loop, this happens automatically. |
All I/O modules in the toolkit have the capability to re-sync the file (trivial for SMILES, not so simple for SDF). In the read loop, this happens automatically. |
||
[[Category:Cactvs/Tcl]] |
[[Category:Cactvs/Tcl]] |
||
+ | [[Category:Cactvs/Python]] |
Revision as of 18:02, 3 October 2013
Parse the strings "Q" and "C1C1" as if they were SMILES and store any error or warning messages to a file. These should not be accepted as valid SMILES strings.
There needs to be a similar test for SD files.
Hmm, even better would be to parse a SMILES file and SD file containing errors, to see if the respective readers can skip the errors.
The idea here is that an application (including a web app) may want to report that an input structure was incorrect, and give some information about what was wrong.
OpenBabel/Rubabel
require 'rubabel'
File.open("log.txt", 'w') do |out|
%w(Q C1C).each do |smile|
Rubabel[smile] rescue out.puts "bad smiles #{smile}"
end
end
Cactvs/Tcl
set fh [open log.txt w] foreach smiles [list "Q" "C1C"] { if {[catch {ens create $smiles} msg]} { puts $fh $msg } } close $fh
The message is "Error: ens create failed: Failed to decode structure data specification"
For file input, you can do something like
while 1 { if {[catch {molfile read $fh} eh]} { if {[molfile get $fh eof]} { break } else { puts $eh continue } } }
All I/O modules in the toolkit have the capability to re-sync the file (trivial for SMILES, not so simple for SDF). In the read loop, this happens automatically.