This is too bad as it indicates a lot of golang programmers are not that aware of maintaining projects for the longer term, nor about the real meaning of cross platform over time.
many golang developers have a hate relationship towards non-standard systems, especially Windows, likely because history has not proven to them yet that systems over time are distinctly different, even in the same family of operating systems
much golang tooling radiate “showing progress or logging is for whimps, it it takes time, wait, or watch a process monitor like ps, task manager or activity monitor), like for instance this issue that has been open for a year https://github.com/golang/dep/issues/1001 [WayBack]
few golang developers understand that there are older versions of make (especially the Borland one) with different syntaxes. The ones that do not, sort of get mad, failing to understand developing software is 80+% maintenance, meaning keeping old stuff around so you are sure you can build things depending on that old stuff.
many of the Makefile entries are filled with bashisms which makes it hard to use with different shells
Microsoft Windows has a code page designated for UTF-8, code page 65001. Prior to Windows 10 insider build 17035 (November 2017),[7] it was impossible to set the locale code page to 65001, leaving this code page only available for:
Explicit conversion functions such as MultiByteToWideChar
The Win32 console command chcp 65001 to translate stdin/out between UTF-8 and UTF-16.
This means that “narrow” functions, in particular fopen, cannot be called with UTF-8 strings, and in fact there is no way to open all possible files using fopen no matter what the locale is set to and/or what bytes are put in the string, as none of the available locales can produce all possible UTF-16 characters.
On all modern non-Windows platforms, the string passed to fopen is effectively UTF-8. This produces an incompatibility between other platforms and Windows. The normal work-around is to add Windows-specific code to convert UTF-8 to UTF-16 using MultiByteToWideChar and call the “wide” function.[8] Conversion is also needed even for Windows-specific api such as SetWindowText since many applications inherently have to use UTF-8 due to its use in file formats, internet protocols, and its ability to interoperate with raw arrays of bytes.
There were proposals to add new API to portable libraries such as Boost to do the necessary conversion, by adding new functions for opening and renaming files. These functions would pass filenames through unchanged on Unix, but translate them to UTF-16 on Windows.[9] This would allow code to be “portable”, but required just as many code changes as calling the wide functions.
With insider build 17035 and the April 2018 update (nominal build 17134) for Windows 10, a “Beta: Use Unicode UTF-8 for worldwide language support” checkbox appeared for setting the locale code page to UTF-8.[a] This allows for calling “narrow” functions, including fopen and SetWindowTextA, with UTF-8 strings. Microsoft claims this option might break some functions (a possible example is _mbsrev[10]) as they were written to assume multibyte encodings used no more than 2 bytes per character, thus until now code pages with more bytes such as GB 18030 (cp54936) and UTF-8 could not be set as the locale.[11]
One of out customer had selected that and we started to experience very weird problems and took some time to find out why it misbehaves.
None of the application could connect to Firebird SQL server (Ours or third party) successfully.
So would be smart to go through all tooling and code with that setting, we never know what M$oft will do with that, will it ever be released or will it soon be default for all.
One of the things that bugged me for a long time is that every now and then for some shapes, when editing their text, the draw.io web interface puts in trailing line feeds after the text, messing up layout.
The easiest way to work around it is by searching inside the diagram XML for
", then replacing that with a ".
(the above code got screwed by WordPress.com saving it, so the search is in this small gist below)
This behaviour is intermittent on the drawio MacOS desktop app.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Every now and then the visual editor at https://t.co/HhHS5rzG2X screws up when saving. For now @WordPress needs to check why the below inside <code> tags gets translated to a line feed, despite the text view having it correctly escaped:https://t.co/pv30Lg9NZW
“It’s due to some Castalia code, that’s merged in Delphi since XE8. It’s only possible to reduce this issue, so it will happen less often. Use: Tools – Options – Editor Options – Color – Structural Highlighting and switch everything off. Looking at how the code is integrated into the IDE, this results in less editor parsing and repainting. Irrespective of that, the handler that causes the Access violation is still attached to the editor. So basically, we will have to wait for this to be fixed in 10.3.”
More recent versions have the old Castalia code base much more rightly integrated, so the only way is to disable Structural Syntax Highlighting in the Editor options.
When I add a file or form to a Delphi project, often I get an access violation. Then I have to restart Delphi, open the project and try it again. Then it sometimes workes, sometimes I get the same Access violation. I am having this issue in all Delphi versions since XE8.
…
Looking at how the code is integrated into the IDE, this results in less editor parsing and repainting. Irrespective of that, the handler that causes the Access violation is still attached to the editor.
I have seen this happen too, but so intermittently that I could not point it back to this code (especially since I usually have Model Maker Code Explorer and GExerts loaded which makes it harder to trace back issues to actual Delphi things).
Back to the HTMLParser descendant in interfaces_dumper.py which can basically be condensed down to the code below.
handle_data is called for both start tags and end tags. The th value in data is only present in the start tag (at the time of end tag the data is empty), so you need to keep track of both last_start_tag and last_end_tag.
handle_endtag maintains last_end_tag to help handle_data.
handle_starttag maintains last_start_tag to help handle_data and also handles the button behaviour.
The buttonis only relevant if it has type="submit" and name="start" and a value attribute in that order.
Output is in data which is an array of key/value pairs.
I’m having some issues which I’m guessing are related to self-referencing using .NET Core Web API and Entity Framework Core. My Web API starting choking when I added .Includes for some navigation
[
The Wiert Corner - irregular stream of stuff 