[Vm-dev] the warnPrintf dilemna

Ben Coman btc at openinworld.com
Sat Jan 5 02:34:58 UTC 2019


On Fri, 4 Jan 2019 at 19:36, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190105/9a0bc03c/attachment-0001.html>


More information about the Vm-dev mailing list