Hi Justin! On Sep 23, 11:55 pm, "Justin C. Walker" <[email protected]> wrote: > > - If one has a big string s, then singular(s) will not directly send s > > to the singular interface, but eventually > > singular._eval_line_using_file(s) is called.In that method, the file > > singular._local_tmpfile() is opened for writing, s is written to it, > > then it is closed. > > - Directly after closing the file, it is read into Singular. I could > > imagine that sometimes it is attempted to read it before closing it > > succeeded. > > - Moreover, if the next large input line occurs, then > > singular._local_tmpfile() is again opened for writing -- perhaps > > before the previous I/O to it was completed? > > I would say, as we did in the 70's and 80's, that's a big 10-4.
... which, according to http://www.urbandictionary.com/define.php?term=big%2010-4, probably means that you enthusiastically agree? I am not a native speaker. > > So, better before than afterwards. Makes sense. > > Again, don't rely on things to happen exactly as you want them to. The > sync() call tells the system (maybe both python and the kernel; not sure how > it's implemented and what kind of cacheing python does) that you want the > data sent to its final resting place. How that happens is up to a lot of > "strategic" code that lives in the kernel and perhaps in python. In general, > think of these calls as telling the underlying system "here's what I want to > happen", not "do this now and come back when you're done". Is there a command that tests for a given file name whether or not there are any I/O operations left to be done on that file? Such command could then be put in a "while" loop. > > I doubt that it would be acceptable to slow down every single call to > > an expect interface by pausing. > > The latter was more of a suggestion to try, with the hopes of understanding > more about what was going wrong. I didn't intend that to be a fix. OK. One problem is: How can one debug it, and how can it be doctested once it is fixed? The errors really occur only sporadically. It is like "run the test suite of my cohomology spkg on t2.math, which takes about 2 hours, and sometimes (but not always, and not always in the same test example) you will see the error". Is there a way to set up an environment on sage.math that has a particularly poor I/O performance? Then, perhaps one can trigger the problem by sending large data through the Gap or Singular interface, in a tight loop. I'll do some experiments. Best regards, Simon -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
