Smalltalk › Squeak › Squeak VM

the warnPrintf dilemna

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Nicolas Cellier

the warnPrintf dilemna

So I have made good progress in making Win32/64 VM -DUNICODE compatible.

minheadless VM already uses -DUNICODE, so all should go well... but...

But now I have some conflicts with minheadless VM.

- minheadless defines warnPrintf as printf (thus taking a char *)

- regular platforms/win32/vm defines it as taking a TCHAR*

it did before me, I did not change it, I just made sure that every sender would provide a TCHAR* thru TEXT() macro. By fixing platforms/win32/plugins for -DUNICODE compatibility, I thus broke win32 minheadless

The problem is not completely blocking: we can just ignore compiler warnings for the moment. Then if the plugin are verbose, the output will be truncated or garbled...

But if we are serious, then we need to unify.

The question is what are the expectations concerning error/warning outputs?

The windows console do handle UTF16 (WCHAR).

But maybe we don't want to output to console?

Another consideration:

- if warnPrintf is used in paltforms/Cross then its signature MUST NOT change from one architecture to another. Before minheadless, it was not used in Cross.

- if warnPrintf is used in several platforms/specific_arch it may take different signatures... but it should rather not, because this is dangerous for us programmers: the risk of making a mistake grows high, the ability to easily review code changes drops down. That's unfortunately the case.

For the case of different signatures, I would be inclined to have different names.

We also have printLastError in windows... which is like perror on Unix, but takes a TCHAR*

DPRINTF for debug purposes which may take many different forms, including warnPrintf.

DBGPRINTF same.

And plenty of direct usage of printf perror...

There are basically two points of view:

- all these functions are services provided by the VM. A plugin should not decide to bypass the VM and directly call underlying OS low level functions. We should then try to officialize those services

- we stick to standard IO stdin stdout stderr paradigm (which might naturally be the point of view of a minheadless VM), but then what about OS conventions like encoding?

Thoughts?

Nicolas Cellier

Re: the warnPrintf dilemna

Le ven. 4 janv. 2019 à 12:35, Nicolas Cellier <[hidden email]> a écrit :

So I have made good progress in making Win32/64 VM -DUNICODE compatible.
minheadless VM already uses -DUNICODE, so all should go well... but...

But now I have some conflicts with minheadless VM.
- minheadless defines warnPrintf as printf (thus taking a char *)
- regular platforms/win32/vm defines it as taking a TCHAR*

it did before me, I did not change it, I just made sure that every sender would provide a TCHAR* thru TEXT() macro. By fixing platforms/win32/plugins for -DUNICODE compatibility, I thus broke win32 minheadless

The problem is not completely blocking: we can just ignore compiler warnings for the moment. Then if the plugin are verbose, the output will be truncated or garbled...

But if we are serious, then we need to unify.
The question is what are the expectations concerning error/warning outputs?
The windows console do handle UTF16 (WCHAR).
But maybe we don't want to output to console?

Another consideration:
- if warnPrintf is used in paltforms/Cross then its signature MUST NOT change from one architecture to another. Before minheadless, it was not used in Cross.
- if warnPrintf is used in several platforms/specific_arch it may take different signatures... but it should rather not, because this is dangerous for us programmers: the risk of making a mistake grows high, the ability to easily review code changes drops down. That's unfortunately the case.

For the case of different signatures, I would be inclined to have different names.

We also have printLastError in windows... which is like perror on Unix, but takes a TCHAR*
DPRINTF for debug purposes which may take many different forms, including warnPrintf.
DBGPRINTF same.
And plenty of direct usage of printf perror...

There are basically two points of view:
- all these functions are services provided by the VM. A plugin should not decide to bypass the VM and directly call underlying OS low level functions. We should then try to officialize those services
- we stick to standard IO stdin stdout stderr paradigm (which might naturally be the point of view of a minheadless VM), but then what about OS conventions like encoding?

Thoughts?

These small steps will guide me for the immediate problem:

- 1) have all warnPrintf defined as taking a char * so as to be uniform across platforms and compatible with minheadless

- 2) provide a warnPrintfW (and warnPrintfT macro for UNICODE agnostic code) for the rare cases that may require Wide char

- 3) define warnPrintfW/T in minheadless too, somewhere in the windows specific headers (it can be simply defined as wprintf)

Ben Coman

Re: the warnPrintf dilemna

In reply to this post by Nicolas Cellier

On Fri, 4 Jan 2019 at 19:36, Nicolas Cellier <[hidden email]> wrote:

So I have made good progress in making Win32/64 VM -DUNICODE compatible.
minheadless VM already uses -DUNICODE, so all should go well... but...

But now I have some conflicts with minheadless VM.
- minheadless defines warnPrintf as printf (thus taking a char *)
- regular platforms/win32/vm defines it as taking a TCHAR*

it did before me, I did not change it, I just made sure that every sender would provide a TCHAR* thru TEXT() macro. By fixing platforms/win32/plugins for -DUNICODE compatibility, I thus broke win32 minheadless

The problem is not completely blocking: we can just ignore compiler warnings for the moment. Then if the plugin are verbose, the output will be truncated or garbled...

But if we are serious, then we need to unify.
The question is what are the expectations concerning error/warning outputs?
The windows console do handle UTF16 (WCHAR).
But maybe we don't want to output to console?

Another consideration:
- if warnPrintf is used in paltforms/Cross then its signature MUST NOT change from one architecture to another. Before minheadless, it was not used in Cross.
- if warnPrintf is used in several platforms/specific_arch it may take different signatures... but it should rather not, because this is dangerous for us programmers: the risk of making a mistake grows high, the ability to easily review code changes drops down. That's unfortunately the case.

For the case of different signatures, I would be inclined to have different names.

We also have printLastError in windows... which is like perror on Unix, but takes a TCHAR*
DPRINTF for debug purposes which may take many different forms, including warnPrintf.
DBGPRINTF same.
And plenty of direct usage of printf perror...

There are basically two points of view:
- all these functions are services provided by the VM. A plugin should not decide to bypass the VM and directly call underlying OS low level functions. We should then try to officialize those services

Just a view from the side-court. It seems coordination between platforms has been fragmented in the past.

Understandable since many contributors probably didn't have a testing-farm on hand to test all platforms

making it was easier and safer to just modify the platform being worked on directly.

But now we have a good CI infrastructure in place to observe the impact all platforms so help can be requested

if a developer doesn't have a local installation of a particular platform, officializing those services seems the right way to go.

That would include promoting them with documentation so its easy for newcomers to know the "right way" to do it.

Perhaps even code quality tests guarding against the low level functions being introduced (but maybe thats a step too far)

- we stick to standard IO stdin stdout stderr paradigm (which might naturally be the point of view of a minheadless VM), but then what about OS conventions like encoding?

The consideration would be how often encoding issues will bump developers out of the "flow" of what they really want to focus on.
i.e. What is the balance of account to pay-now or pay-later. I haven't dealt much with encoding issues, so I can't judge.

cheers -ben