Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 15, 2020 Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
../../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'. |
August 16, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joel | 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
|
August 16, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjærås | 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
|
August 16, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Simen Kjærås | 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.
|
August 17, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anonymouse | 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.
|
August 18, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anonymouse | 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.
|
September 19, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | 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?
|
September 19, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anonymouse | 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 |
September 19, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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?
|
September 19, 2020 Re: Cannot call @system funciton (stdout) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anonymouse | 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.
|
Copyright © 1999-2021 by the D Language Foundation