On Wednesday, October 23, 2019 at 9:49:56 PM UTC-7, Nils Bruin wrote:
>
> On Wednesday, October 23, 2019 at 2:47:54 PM UTC-7, John H Palmieri wrote:
>>
>>
>>
>> On Wednesday, October 23, 2019 at 1:41:35 PM UTC-7, Nils Bruin wrote:
>>>
>>> On Wednesday, October 23, 2019 at 1:26:46 PM UTC-7, John Cremona wrote:
>>>>
>>>>
>>>> That all looks very complicated. Before I fixed the eclib source code
>>>> the previous method did work, namely to flush stdout and stderr from the
>>>> c/python wrapper code after calling any library function (in some cases
>>>> this is certainly redundant, but in the case of eclib it was very hard for
>>>> anyone other than me to know which library functions might spit out some
>>>> error or warning message). Somewhere in src/sage/libs/flint are the
>>>> wrapper functions which need this.
>>>>
>>>> Given that fflush is a system call, it probably has quite a serious
>>> overhead. When the routine is meant to do I/O anyway, it's a fair price to
>>> pay, but just flushing on the odd chance that a warning was generated could
>>> very well be quite costly. For a low-level library like flint, that might
>>> be too high a price. I think you want to test for performance regression
>>> before working around lacking output flushes by flushing always.
>>>
>>
>> Is there a way to just flush output immediately after the relevant
>> doctest? For the record, the doctest is
>>
>> FLINT memory errors do not crash Sage (:trac:`17629`)::
>>
>> sage: t^(sys.maxsize//2)
>> Traceback (most recent call last):
>> ...
>> RuntimeError: FLINT exception
>>
>> Wouldn't something like
>
> try:
> t^(sys.maxsize//2)
> except:
> sys.stdout.flush()
> raise
>
> do the trick, to ensure that the message gets flushed before the error
> gets raised?
>
> shouldn't a message like that occur on sys.stderr, though?
>
The relevant print command in FLINT is
flint_printf("Exception (FLINT memory_manager). Unable to allocate
memory.\n");
and the problem is fixed by adding
fflush(stdout);
So maybe it should be on stderr, but it's not. Regarding
sys.stdout.flush(), my understanding, as confirmed by my experience with
this particular problem, is that this only flushes output coming from
Python, not from external library calls.
>
>
>
>
>> and the "..." is supposed to capture "Exception (FLINT memory_manager).
>> Unable to allocate memory." This text is what needs to be flushed, because
>> otherwise it may not appear here, instead appearing in the output of some
>> later doctest. So if we can add something at the end of the doctest, an
>> analogue of
>>
>> sage: sys.stdout.flush()
>> ...
>>
>> that could work and would not impact performance whenever FLINT is used.
>>
>> --
>> John
>>
>>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sage-devel/689a01d2-8291-47fd-9798-8b9d3e0d840d%40googlegroups.com.
