../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function jmisc.base.upDateStatus!string.upDateStatus cannot call @system function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
/Library/D/dmd/src/phobos/std/stdio.d(4837,20):        std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here

I got around it by avoiding 'stdout'.

On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
> ../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function jmisc.base.upDateStatus!string.upDateStatus cannot call @system function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
> /Library/D/dmd/src/phobos/std/stdio.d(4837,20):        std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here
>
> I got around it by avoiding 'stdout'.

First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p

stdout is __gshared, so it's available on any thread at any time. That's not @safe, so it's @system.

If you know you're not using stdout from multiple threads, or don't care (it might be perfectly safe even though it's possible to misuse), you can use this code:

@property File trustedStdout() @trusted
{
    return stdout;
}

That's a @trusted wrapper that you can call from @safe code. It's not actually safe though, as multiple threads could be using trustedStdout at the same time. In many use cases, this is unlikely to matter, but it's wroth keeping in mind.

--
  Simen

On 8/16/20 6:07 AM, Simen Kjærås wrote:
> On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
>> ../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function jmisc.base.upDateStatus!string.upDateStatus cannot call @system function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
>> /Library/D/dmd/src/phobos/std/stdio.d(4837,20): std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here
>>
>> I got around it by avoiding 'stdout'.
> 
> First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p
> 
> stdout is __gshared, so it's available on any thread at any time. That's not @safe, so it's @system.
> 
> If you know you're not using stdout from multiple threads, or don't care (it might be perfectly safe even though it's possible to misuse), you can use this code:
> 
> @property File trustedStdout() @trusted
> {
>      return stdout;
> }
> 
> That's a @trusted wrapper that you can call from @safe code. It's not actually safe though, as multiple threads could be using trustedStdout at the same time. In many use cases, this is unlikely to matter, but it's wroth keeping in mind.

Technically, there's nothing unsafe about reading stdout, as long as you are not setting it. Otherwise, writeln wouldn't be @safe (as all it does is call a private trustedStdout).

The whole thing is messy IMO, and should be revisited.

-Steve

On Sunday, 16 August 2020 at 10:07:02 UTC, Simen Kjærås wrote:
> On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
>> ../../JMiscLib/source/jmisc/base.d(176,2): Error: @safe function jmisc.base.upDateStatus!string.upDateStatus cannot call @system function std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal
>> /Library/D/dmd/src/phobos/std/stdio.d(4837,20):        std.stdio.makeGlobal!"core.stdc.stdio.stdout".makeGlobal is declared here
>>
>> I got around it by avoiding 'stdout'.
>
> First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p

Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.

On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
> On Sunday, 16 August 2020 at 10:07:02 UTC, Simen Kjærås wrote:
>> On Saturday, 15 August 2020 at 23:59:36 UTC, Joel wrote:
>>> [...]
>>
>> First, what's wrong with using writeln and friends instead of directly mucking about with stdout? :p
>
> Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.

Yeah, that's probably the only thing I've used 'stdout' for so far - flush.

On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
> Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.

Cygwin terminals are not recognized as terminals, you should set line buffered mode, then it will flush every line.

On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:
> On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
>> Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.
>
> Cygwin terminals are not recognized as terminals, you should set line buffered mode, then it will flush every line.

How do I do this?

On Saturday, 19 September 2020 at 13:23:29 UTC, Anonymouse wrote:
> On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:
>> On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
>>> Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.
>>
>> Cygwin terminals are not recognized as terminals, you should set line buffered mode, then it will flush every line.
>
> How do I do this?

http://dpldocs.info/experimental-docs/std.stdio.File.setvbuf.1.html

On Saturday, 19 September 2020 at 13:32:07 UTC, Paul Backus wrote:
> On Saturday, 19 September 2020 at 13:23:29 UTC, Anonymouse wrote:
>> On Tuesday, 18 August 2020 at 06:25:31 UTC, Kagamin wrote:
>>> On Sunday, 16 August 2020 at 18:13:07 UTC, Anonymouse wrote:
>>>> Just as a drive-by comment, the main stdio thing I came across that I couldn't do from within @safe was stdout.flush(), which I need to call manually for Cygwin terminals and some terminals embedded in editors (vscode). If someone knows why, please tell me.
>>>
>>> Cygwin terminals are not recognized as terminals, you should set line buffered mode, then it will flush every line.
>>
>> How do I do this?
>
> http://dpldocs.info/experimental-docs/std.stdio.File.setvbuf.1.html

Thanks.

I don't have a clone of druntime/Phobos available to me right now, so some follow-up questions.

It looks like full buffering _IOFBF is the default setting, but "normal" non-Cygwin stdio certainly seems to do line buffering. Is it getting set to line buffering _IOLBF during initialisation of stdout? (Why then is Cygwin exempt?)

Is there a way to detect programmatically if I'm in an environment where I need to manually set line buffering?

On Saturday, 19 September 2020 at 13:56:53 UTC, Anonymouse wrote:
> Is there a way to detect programmatically if I'm in an environment where I need to manually set line buffering?

Part of the problem is the IDE console and cygwin too I believe both *look* like a pipe to the program instead of like an interactive terminal, thus why it gets block instead of line buffered.

Someone once told me of a trick to detect cygwin specifically but I can't access it right now and I'm not sure it would work reliably anyway....

Just yeah set your expectations low because if it was easy to tell programmatically the libc would already do it right.