Hi!
On 25 Sep., 00:08, Simon King wrote:
> So, I'll try to fix the Expect.quit() method.
To sum it up:
* Expect.quit() needs to get rid of self.__local_tmpfile
* Expect._local_tmpfile() uses self.__local_tmpfile, or computes a
new filename that depends on self.pid() and is unique for the given
Hi!
I think I made a progress in understanding why @parallel works well
with pid, but not well with the double-underscore __local_tmpile
attribute.
The @parallel decorator calls p_iter_fork, and this calls
sage.interfaces.quit.invalidate_all.
So, let us see what happens:
sage: s = gap._local_tm
Hi all!
On 24 Sep., 20:39, "Justin C. Walker" wrote:
> The fact that all (or some) instances use the same file make it a
> race condition for sure. It's just that in this case, there may be a
> very simple fix for it (Ryan's suggestion of using distinct temp
> files, for example).
Well, a
Hi, Simon,
On Sep 24, 2010, at 11:00 AM, Simon King wrote:
On 24 Sep., 19:38, "Justin C. Walker" wrote:
That is the crux of the problem. This is a race condition (multiple
outcomes, depending on the ordering of operations, many of which are
outside of your control. Debugging of these proble
Hi Justin!
On 24 Sep., 19:38, "Justin C. Walker" wrote:
> That is the crux of the problem. This is a race condition (multiple
> outcomes, depending on the ordering of operations, many of which are
> outside of your control. Debugging of these problems is why we pay
> software developers t
On Sep 24, 2010, at 1:16 AM, Simon King wrote:
Hi Justin!
On Sep 23, 11:55 pm, "Justin C. Walker" 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
sin
On 24 Sep., 19:01, Simon King wrote:
> ...
> * Why is it not possible to access gap.__local_tmpfile, even though
> this attribute *can* be accessed from inside the method?
Conversely, if I set the attribute, why is it ignored inside the
_local_tmpfile method?
sage: gap.__local_tmpfile = 'foobar'
Hi Ryan!
On 24 Sep., 18:13, Ryan Hinton wrote:
> Have you considered Python's tempfile module?
>
> http://docs.python.org/library/tempfile.html
No, I didn't, yet.
Since the different Gap instances in the parallelised function have
different pid, it would solve the problem to make the _local_tmp
On Sep 24, 8:49 am, Simon King wrote:
> On Sep 24, 3:16 pm, Simon King wrote:
>
> > Doing so, the gap and singular interfaces get different file names,
>
> Works.
>
> > and moreover the trouble with the @parallel decorator vanishes.
>
> Doesn't. Sorry, another idea is needed.
Have you considered
On Sep 24, 3:16 pm, Simon King wrote:
> Doing so, the gap and singular interfaces get different file names,
Works.
> and moreover the trouble with the @parallel decorator vanishes.
Doesn't. Sorry, another idea is needed.
--
To post to this group, send an email to sage-devel@googlegroups.com
T
Hi!
There is one more issue:
sage: print gap._local_tmpfile()
/home/king/.sage//temp/gauss/16746//interface//tmp16746
sage: print singular._local_tmpfile()
/home/king/.sage//temp/gauss/16746//interface//tmp16746
If gap and singular share one _local_tmpfile, there is another
potential source of tr
On Sep 24, 1:52 pm, Simon King wrote:
> ...
> I am about to open a ticket for that issue.
It is #10004, and I marked it as blocker for sage 4.6.1, since I think
that both parallelisation and interfaces are important enough to make
this mandatory for a three-digit (== bug fix) release.
Cheers,
Si
Hi!
I think I found the problem, but can not locate it in the interface
code, yet.
My test suite uses the @parallel decorator, in order to run several
tests at the same time.
Under normal circumstances, the gap instances in different branches of
a parallelised function have distinct _local_tmpfi
Hi Justin!
On Sep 23, 11:55 pm, "Justin C. Walker" 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 w
Hi, Simon,
On Sep 23, 2010, at 15:38 , Simon King wrote:
> On 24 Sep., 00:04, "Justin C. Walker" wrote:
>> For most unix-like systems, it's generally not true that a close() of a file
>> descriptor will wait until the file is closed.
>
> Thank you, that's good to know! Then it seems more than
Hi Justin!
On 24 Sep., 00:04, "Justin C. Walker" wrote:
> For most unix-like systems, it's generally not true that a close() of a file
> descriptor will wait until the file is closed.
Thank you, that's good to know! Then it seems more than likely to me
that there's the problem with the expect
On Sep 23, 2010, at 13:22 , Simon King wrote:
> On 23 Sep., 21:11, Simon King wrote:
>> ...
>> I would expect that F.close() waits until the file F really is closed,
>> but perhaps I am mistaken?
For most unix-like systems, it's generally not true that a close() of a file
descriptor will wait
On 23 Sep., 21:11, Simon King wrote:
> ...
> I would expect that F.close() waits until the file F really is closed,
> but perhaps I am mistaken?
>
> Anyway, it does occasionally happen to me (but it is hardly
> reproducible) that the temporary file is mutilated when
> self._eval_line(self._read_in
18 matches
Mail list logo
