wtr | 这里记录值得阅读有趣的技术内容 , 内容开源于 GitHub : xiaofuzi/wtr，欢迎提交 issue，推荐内容。 | Parser library

If I understand you correctly, you want to add a time column to your csv file. The time column is to hold timestamps with a five minute interval.

I recommend using pandas when dealing with csv files, because pandas dataframes are so easy to manipulate. See the below code and let me know if it solves your problem.

It's not totally clear what the question is, given that the code appears to compile, but I can take a stab at one part: why can't you use into_inner() on self.wtr inside the process function?

into_inner takes ownership of the PacketWriter that gets passed into its self parameter. (You can tell this because the parameter is spelled self, rather than &self or &mut self.) Taking ownership means that it is consumed: it cannot be used anymore by the caller and the callee is responsible for dropping it (read: running destructors). After taking ownership of the PacketWriter, the into_inner function returns just the wtr field and drops (runs destructors on) the rest. But where does that leave the Something struct? It has a field that needs to contain a PacketWriter, and you just took its PacketWriter away and destroyed it! The function ends, and the value held in the PacketWriter field is unknown: it can't be thing that was in there from the beginning, because that was taken over by into_inner and destroyed. But it also can't be anything else.

Rust generally forbids structs from having uninitialized or undefined fields. You need to have that field defined at all times.

Here's the worked example:

The error message tells you all you need to know - from_path returns a Result rather than a WriterBuilder, because opening that file might not always work. That is different with from_writer - no file needs to be opened, so no possibility of encountering an error.

To fix this, you can just use .unwrap(), like you do with serde_json::from_str the line below. This will cause a panic when an error was encountered, immediately terminating your program.

You can use torch.autograd.grad function to obtain gradients directly. One problem is that it requires the output (y) to be scalar. Since your output is an array, you will still need to loop through its values.

The call will look something like this.

How about adjusting option 1:

Make the program take two arguments: file jobnumber

After sending quit to bc it terminates which closes the reading end of the pipe. Your next print $WTR $_ will then fail and generate the SIGPIPE signal that terminates the program - unless you install a signal handler for it.

An alternative solution could be to check that reading from bc after you've sent something to it succeeds:

You can get a pretty substantial improvement by following the performance tips in the tutorial you linked. In particular, the key is really to amortize allocations and avoid a UTF-8 check, both of which are happening in your code. Namely, your code allocates a new record in memory for each row in the CSV file. It also checks each field for valid UTF-8. Both of these have costs, but they do provide a fairly simple API that is decently fast as it is.

Additionally, one tip that isn't mentioned in the tutorial is to use csv::Writer::write_byte_record when possible instead of csv::Writer::write_record. The latter is more flexible, but the former constrains the input a bit more such that it can implement writes more efficiently in common scenarios.

Overall, making these changes is pretty easy: