kicad-developers team mailing list archive
Mailing list archive
Re: 6.0 string proposal
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Fri, 3 May 2019 10:41:42 -0400
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
On 5/3/19 5:22 AM, Jeff Young wrote:
> Hi Dick,
>>> h) What is the list of deficiencies with current string usage?
> I only have one issue with the current use of wxString, but it’s a big
> one: it crashes (unpredictably) when used multi-threaded in UTF8 mode.
I thought it was wxString itself that was not thread safe not
necessarily the utf-8 build but thread safety is the primary goal now
that we are using threads in multiple places within KiCad.
On my Debian system wx/setup.h shows
#define wxUSE_UNICODE 1
#define wxUSE_UNICODE_UTF8 0
so it would appear that wxString is built for unicode not utf8 mode on
linux. I'm also pretty sure windows builds are unicode as well.
There is a secondary goal of removing wxWidgets from our low level
objects. Maybe some day we can build the low level KiCad non-ui
libraries sans wxWdigets. My thinking is that wxString should only come
into play at the UI level when dealing with wxWidgets UI code. Being
able to use a standard C++ string implementation would (may?) go a long
way in helping with that goal.
> This design document makes for fascinating
> reading: https://wiki.wxwidgets.org/Development:_UTF-8_Support. It
> appears that the current wxString is at least in part modelled on QtString.
> There’s also a bunch of interesting info
> here: https://docs.wxwidgets.org/trunk/overview_string.html, which I
> believe is more up-to-date than the previous link. In particular,
> there’s the mention that wxString handles extra-BMP characters
> transparently when compiled in UTF8 mode (currently used by Kicad), but
> does NOT when compiled in default mode (in which case the app must
> handle surrogate pairs). This of course directly leads to your point (d):
>>>> d) What does the set of characters that don't fall into UCS2
>>>> actually look like? How big
>>>> is this set, really? (UTF16 is bigger than UCS2 and picks up the
> Do we really need to handle extra-BMP characters?
> An even more recent version of the second document
> (https://docs.wxwidgets.org/trunk/classwx_string.html) finally makes an
> oblique reference to the multi-threading issue by starting with this
> (rather unhelpful) suggestion:
> While the use of wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> is
> unavoidable in wxWidgets program, you are encouraged to use the
> standard string classes |std::string| or |std::wstring| in your
> applications and convert them to and from wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> only when
> interacting with wxWidgets.
>> On 3 May 2019, at 02:03, Dick Hollenbeck <dick@xxxxxxxxxxx
>> <mailto:dick@xxxxxxxxxxx>> wrote:
>> On 5/2/19 5:32 PM, Dick Hollenbeck wrote:
>>> On 4/30/19 4:36 AM, Jeff Young wrote:
>>>> We had talked earlier about throwing the wxWidgets UTF8 compile
>>>> switch to get rid of our wxString re-entrancy problems. However, I
>>>> noticed that the 6.0 work packages doc includes an item for
>>>> std::string-ization of the BOARD. (While a lot more work, this is a
>>>> better solution because it also increases our gui-toolkit-choice
>>>> I’d like to propose that we use std::wstring for that. UTF8 should
>>>> *only* be an encoding format (similar to s-expr). It should never
>>>> be used internally. That’s what unicode wchar_t’s are for.
>>>> And I’d like to propose that we extend std::wstring-ization to
>>>> SCH_ITEM and LIB_ITEM. (Then we can get rid of a bunch of our ugly
>>>> mutex hacks.)
>>> I've been looking at this for a few months now. I think it is so
>>> important, that a
>>> sub-committee should be formed, and if that committee takes as long
>>> as 4 months to come to
>>> a recommendation, this would not be too long. This issue is simply
>>> too critical.
>>> I would like to volunteer to be on that committee. For the entire
>>> list to participate in
>>> this simply does not make sense to me. I would welcome the
>>> opportunity to study this with
>>> a team of 5-6 players. More than that probably leads to anxiety.
>>> Then, given the
>>> recommendations, the list would of course have an opportunity to
>>> raise questions and take
>>> shots, before a strategy is formulated, and before anything is
>>> Again, approximately:
>>> committee recommendations -> list approval -> strategy formulation
>>> -> implementation
>>> Up to now I have looked at many libraries and have [way *too* much]
>>> experience in multiple
>>> languages on multiple platforms, so I think I can be valuable
>>> The final work product initially would simply be a list of
>>> recommendations, that quickly
>>> transforms to a strategy thereafter. This is an enormous
>>> undertaking, so I suggest
>>> against racing to a solution. It could look a lot easier than it
>>> will ultimately be, as
>>> is typical in software development. But the return on investment
>>> needs to be near optimal
>>> in the end.
>>> Some questions to answer are:
>>> a) How did wxString get to its current state? Is is merely a
>>> conglomeration of after
>>> thought, or is is anywhere near optimal.
>>> b) Why so many forms of it? Can one form be chosen for all platforms?
>>> c) How does wxString it compare to QtString?
>>> d) What does the set of characters that don't fall into UCS2 actually
>>> look like? How big
>>> is this set, really? (UTF16 is bigger than UCS2 and picks up the
>>> e) For data files, I think UTF8 is fine. So the change is for RAM
>>> manipulation of
>>> strings. Aren't we talking about a RAM resident string that bridges
>>> into the GUI seamlessly?
>>> f) What does new C++ language support offer?
>>> g) What do C++ language designers suggest?
>> h) What is the list of deficiencies with current string usage?
>>> But this is best continued in a smaller group, as said.
>>> The other thing that I bring to this is vast familiarity with KiCad's
>>> internal workings,
>>> string use cases, and goals.
>>> Let me know if I can help.
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp