[Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?

[Henner Zeller]

Hi,
I often use the excellent raytracing mode to get a nice 3D view of the board.

The rendering of the individual blocks is done in a Morton sequence,
possibly to minimize cache-miss penalties.

Since this render sequence starts in one corner, it usually takes a
while until the "meat" of the render hits the interesting parts in the
middle of the board.

So I implemented an alternative sequence: from the center out, in a
growing circle. To ease the time long renders take, it is actually two
complementing checkerboard patterns in consecutive passes (hard to
explain, you have to patch and look for yourself). I find this much
more pleasing to watch and also it helps to early see for the user if
they want to adjust the view as the important parts are rendered
first.

Of course, this will be slightly slower (possibly due to cache
issues), but in measurements on my machine this is typically in the
imperceptible noise (9.0 seconds vs. 9.1 seconds for instance).

Given that there might be a performance penalty I prepared two
patches: one that just does the rendering from the center, and one
which provides a setting in the menu-bar to give full choice.
(it might be good for comparison the two types of renderings, but
given the complexity and the added end-user confusion and the
essentially imperceptible performance penalty, I'd tend towards just
using the simple implementation without menu-bar settings).

Anyway, attached you find two patches:
raytrace-from-center-always.patch just does as described above,
without setting.
The raytrace-from-center-with-menubar-setting.patch goes all the way
of having a menu-bar choice and storing the setting in a configuration
(more complex, less preferred).

These patches are against the 5.1 branch, but it also applies cleanly to master.

Cheers,
  Henner.
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index b059cfeaf..72274ac4b 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "c3d_render_raytracing.h"
 #include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
 }
 
 
+static float distance(const SFVEC2UI &a, const SFVEC2UI &b)
+{
+const float dx = (float)a.x - (float)b.x;
+const float dy = (float)a.y - (float)b.y;
+return hypotf(dx, dy);
+}
+
 void C3D_RENDER_RAYTRACING::initialize_block_positions()
 {
 
@@ -2123,26 +2131,32 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
 m_postshader_ssao.UpdateSize( m_realBufferSize );
 
 
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
 // /
 m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
-  (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
-   DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve( blocks_x * blocks_y );
+
+for (int x = 0; x < blocks_x; ++x)
+for (int y = 0; y < blocks_y; ++y)
+m_blockPositions.push_back(SFVEC2UI(x * RAYPACKET_DIM,
+y * RAYPACKET_DIM));
+
+const SFVEC2UI center(m_realBufferSize.x/2, m_realBufferSize.y/2);
+std::sort(m_blockPositions.begin(), m_blockPositions.end(),
+  [&](const SFVEC2UI &a, const SFVEC2UI &b)
+  {
+  // Sort order:
+  // 1) One type of checkerboard pattern first
+  // 2) then inside out
+  const bool half_a = ((a.x / RAYPACKET_DIM) % 2) ^ ((a.y / RAYPACKET_DIM) % 2);
+  const bool half_b = ((b.x / RAYPACKET_DIM) % 2) ^ ((b.y / RAYPACKET_DIM) % 2);
+  if (half_a == half_b)
+  return distance(a, center) < distance(b, center);
+  return half_a < half_b;
+  });
 
 // Create m_shader buffer
 delete[] m_shaderBuffer;
diff --git a/3d-viewer/3d_enums.h b/3d-viewer/3d_enums.h
index 7ff5d1403..2c56c3528 100644
--- a/3d-viewer/3d_enums.h
+++ b/3d-viewer/3d_enums.h
@@ -56,6 +56,7 @@ enum DISPLAY3D_FLG {
 FL_RENDER_RA

[Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show

[Henner Zeller]

Hi,
so here one digit patch.

Problem Symptom: in the schematic symbol chooser, if you search for an
exact match of a component with multiple units, it is not selected.
For instance, search for

   74LS00

The scored element is in the tree, but you need to manually unfold it
(see before.png image). This usually works otherwise (I suspect it has
to do with the fact that there are sub-units).

The attached change will reliably select the first unit of that
particular symbol and fix the problem (after.png image).

Now it might be up for debate if the search should actually unfold to
the first unit or if the tree unfolding should stop at the 74LS00 part
- I guess if the latter is wished, something dependent on
tree-children needs to be introduced. I leave that up to you.

Attached: patch (against 5.1 branch), before image and after image.

Cheers,
  Henner.
diff --git a/common/lib_tree_model_adapter.cpp b/common/lib_tree_model_adapter.cpp
index 0a26788af..6ce97930c 100644
--- a/common/lib_tree_model_adapter.cpp
+++ b/common/lib_tree_model_adapter.cpp
@@ -451,7 +451,7 @@ LIB_TREE_NODE* LIB_TREE_MODEL_ADAPTER::ShowResults()
[]( LIB_TREE_NODE const* n )
{
// return leaf nodes with some level of matching
-   return n->Children.size() == 0 && n->Score > 1;
+   return n->Children.size() == 0 && n->Score > 0;
},
&highScore );
 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kudos to Michael Kavanagh

[Maciej Suminski]

Finished, all 'fix committed' either have been changed to 'fix released'
or had a target assigned.

Cheers,
Orson

On 5/1/19 2:05 AM, Maciej Suminski wrote:
> Status update: I have just updated bug reports targeted at 5.1.0-rc2 (I
> forgot about this last time), 5.1.1, 5.1.2 and those that have not had a
> milestone assigned, but have been committed before 5.1.0 release date.
> 
> All bugs fixed after this date, might have been fixed either in 5.1 or
> 6.0 branch, so have to be treated manually. Fortunately there are just a
> few of them and I will sort them soon.
> 
> Cheers,
> Orson
> 
> On 4/30/19 4:37 PM, Maciej Suminski wrote:
>> On 4/29/19 8:51 PM, Seth Hillbrand wrote:> Orson and I were discussing
>> giving Janitor the power to cleanup all bugs
>>> with Fix Committed prior to v5.1 as Fix Released.  That should take care
>>> of the majority.
>>>
>>> -S
>>
>> I am still traveling, but I am sure I will find some spare time to do
>> this soon. Do not spend time on a task that can be automated.
>>
>> Cheers,
>> Orson
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Pcbnew display origin transforms for v6

[Reece R. Pollack]

Inspired by KiCon (and before the high wears off) I'm moving forward 
with my project to allow the user to specify the coordinate display 
origin in pcbnew. I have this working as patches to the v5.1.2 branch, 
but they're hard-coded to use the Aux origin. I'd like some guidance on 
how best to code this for eventual inclusion into the v6 development branch.


My plan is:

1. Create a new class ORIGIN_TRANSFORM. This class maintains the user's
   configuration and provides functions to perform the transforms
   necessary to convert between the internal coordinate representation
   and the equivalent coordinates relative to the user-selected origin.
2. Embed two ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS
   class representing the origin transforms for the X and Y axes.
3. Create a new tab in the pcbnew "Preferences" to allow the user to
   select the origin (Page [default], Aux, or Grid) and direction (Left
   or Right [default], Up or Down [default]) for each axis.
4. Modify the board file format to save and load the user's
   ORIGIN_TRANSFORM configuration. Saving this in the .kicad_pcb file
   allows everyone editing the board to see coordinates reported
   relative to the same origin.
5. Modify each of the dialog classes that displays object coordinates
   to use the ORIGIN_TRANSFORM objects to display coordinates relative
   to the user-selected origin. When the dialog is closed object
   coordinates are converted back to internal coordinates.
6. Modify the PCB_BASE_FRAME class to display the absolute cursor
   position relative to the user-selected origin.

This is structured to allow the UNIT_BINDER class to manage origin 
transforms, much like it handles the mm/mil conversions. I would change 
the constructor to take a reference to an ORIGIN_TRANSFORM object as an 
additional argument; the default value would be a unity-transform whose 
conversion functions return the value to be converted unmodified. Those 
UNIT_BINDER objects that represent a coordinate value (commonly m_posX 
and m_posY) would be constructed with a reference to one of the two 
ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class.


The problem with this strategy is that KiCad reuses UNIT_BINDER objects 
for dissimilar purposes. For example, 
DIALOG_GRAPHIC_ITEM_PROPERTIES::m_endX can represent the end point of a 
graphic line, for which origin transform is needed. But it can also 
represent the radius of a circle, for which origin transform is 
inappropriate. Thus UNIT_BINDER needs a method similar to the Show() 
function to enable or disable the origin transform depending on how it 
is being used. This may argue against pushing this functionality into 
UNIT_BINDER.


If I don't modify the UNIT_BINDER class I'll probably code the 
ORIGIN_TRANSFORM class to handle wxPoint objects rather than individual 
coordinates. Thus there would be only one ORIGIN_TRANSFORM object added 
to the BOARD_DESIGN_SETTINGS class. The transform in the dialog class 
then becomes a single call to transform a coordinate pair rather than 
one each for X and Y.


Thoughts? Comments? Suggestions? Brickbats?

-Reece


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jon Evans]

String access is a factor in the performance of the new real-time
connectivity algorithm in eeschema, since all connectivity is established
by parsing labels and pin names.  I have not done benchmarks comparing
various options for string storage, but we would need to watch that space
too if we change how strings work.

-Jon

On Tue, Apr 30, 2019 at 8:41 PM John Beard  wrote:

> On 30/04/2019 16:01, Jeff Young wrote:
> > Primarily for performance reasons.
>
> WRT performance, I did a few benchmarks for reference (on Linux)
>
> Loading this large CIAA PCB[1] allocates, out of a peak usage of 467MB
> of heap with a 0.01% threshold:
>
> * 9.6MB of std::basic_string::_M_assign
> * 9.4MB of this is from wxString operator= assignments
> * ~600kB of std::basic_string::_M_construct, (wxString ctor)
>
> So I'm not sure memory usage is a major factor to worry about (strings
> allocate storage on the heap, so we should see basically all the
> interesting things in the heap profile). UTF-8 could be as little as 1/4
> UTF-32 (all strings are ASCII), but even then, it's a few MB saved.
>
> Now, in terms of performance, opening Pcbnew with no file gives:
>
> #4  3.36%   __gconv_transform_utf8_internal
> #5  2.51%   __mbsrtowcs_l
> #6  2.50%   wxMBConv::ToWChar
> #8  2.07%   std::basic_string::_M_assign
> #9  1.88%   wxMBConvStrictUTF8::ToWChar
> #14 1.27%   EscapeString (kicad function)
> #17 0.85%   __GI___strlen_sse2
>
>   #18 0.85%  wxUniChar::From8bit
>
>
> #19 0.84%  wxUniChar::operator==
>
> And plenty more string-y things in the top 50 or so lines. So it seems
> the biggest cost for strings is converting them from UTF-8 to wchar_t
> strings in WX (this is probably not the same on Windows). But it's not
> really a stunning cost.
>
> However, loading the CIAA board, and there are basically no string
> operations above 0.5%, and only a handful even above 0.25%. When doing
> DRC, strings don't break 0.1%: nearly all the significant work is
> looking things up in std::maps and geometry.
>
> So string performance doesn't seem to be *that* critical, as it's
> quickly drowned out under real workloads. It looks to me (and I'm happy
> to be corrected, I'm not a perf expert), like string operations in KiCad
> are not much of a bottleneck.
>
>  > Because characters are different lengths, you have to scan the string
>  > to find the n’th character.
>
> Even with UTF-32, you can only do an O(1) lookup of the n'th *code
> point* or *code unit* (the same in UTF-32, not in UTF-8), not the n'th
> *encoded character*.
>
> That's true even if you normalise the strings first. Not all code points
> map one-to-one to an encoded character (it can be one-to-none,
> one-to-one, many-to-one). And that's even without considering grapheme
> clustering.
>
> Cheers,
>
> John
>
> PS / OT: If we had to optimise one thing,
> PolygonTriangulation::Vertex::inTriangle is the single hungriest
> function, chewing 6.19% of all CPU time, double that of each of the next
> 3: __gnu_cxx::__exchange_and_add (2.76%),  PolygonTriangulation::isEar
> (2.73%) and even malloc (2.27%).
>
> Other than that fairly mundane 6%-er, there are no eye-popping
> performance hogs simply on loading a PCB. Which is nice.
>
> [1]:
>
> https://github.com/ciaa/Hardware/blob/master/PCB/ACC/CIAA_ACC/ciaa_acc.kicad_pcb
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kudos to Michael Kavanagh

[Maciej Suminski]

Status update: I have just updated bug reports targeted at 5.1.0-rc2 (I
forgot about this last time), 5.1.1, 5.1.2 and those that have not had a
milestone assigned, but have been committed before 5.1.0 release date.

All bugs fixed after this date, might have been fixed either in 5.1 or
6.0 branch, so have to be treated manually. Fortunately there are just a
few of them and I will sort them soon.

Cheers,
Orson

On 4/30/19 4:37 PM, Maciej Suminski wrote:
> On 4/29/19 8:51 PM, Seth Hillbrand wrote:> Orson and I were discussing
> giving Janitor the power to cleanup all bugs
>> with Fix Committed prior to v5.1 as Fix Released.  That should take care
>> of the majority.
>>
>> -S
> 
> I am still traveling, but I am sure I will find some spare time to do
> this soon. Do not spend time on a task that can be automated.
> 
> Cheers,
> Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[John Beard]

On 30/04/2019 21:55, Jeff Young wrote:

I think we’re a long way from handling Hiragana, Katakana or Kanji.  Probably 
the same for Tamil or Telegu, although I know nothing about them.


We can already accept Unicode from many string user inputs. For example 
a net name can be "🇺🇸" (this is 2 code points, but might render as a 
flag or a "US"). It doesn't render on the schematic (you see ??) but it 
does make it into the netlist just fine. At least on Linux with a UTF-8 
locale.


If we get user fonts in schematics (e.g. to support Chinese users 
without making our own 1+ char Hershey font[1], this will Just Work 
(TM). This is on the Road Map V6[2].


Anywhere text comes in from the user, could be any kind of weird 
Unicode. Generally 95% of the Unicode handling is taking data from the 
user, keeping it safe, and then passing it onto something that can deal 
with the hellish mess of glyphs. Like HarfBuzz[3] (used by toolkits like 
GTK+ and, directly, by Inkscape). As far as we are concerned, it is 
opaque data.



So why do we scan strings?  We do it when tokenizing, but all our tokens are 
roman (if not ascii), so that should be OK.


In this case we'd be iterating the strings anyway, not random access. 
Parsing s-expressions should be as well defined in Unicode as in ASCII, 
it's a matter of what the grammar accepts (not that there is a formal 
grammar, but if there were one, it would probably say ASCII only symbols 
and anything goes between the quotes of a string, and we'd check for 
valid UTF-8 at some point, but maybe not in the tokenising stage).



We also do it looking for numbers to increment.  We’d like this to work for 
other languages, but as long as their subsequent-code-points don’t look like 
roman digits I think we’re OK.  (Subsequent-code-points are all above ascii, 
right?).


Subsequent code *units* in a code point (in UTF-8, where a unit is 1 
byte and a point is 1-4 bytes) start with 0b10. There's no rule about 
what order code *points* can come in, but some orders make sense, other 
orders are nonsense to humans[4].


Parsing some arbitrary sequence of code points and getting something 
semantically useful out is "hard", and highly domain-specific (like, is 
0xAB a number? I would say so, but my non-computery friends will say no. 
What about 一百零五?). But it would still be done on a iterative basis.



We do some case conversions when doing compares.  But again, as long as 
subsequent code points don’t look like ascii we should be OK.  I assume 
capitalization algorithms don’t try to do it on Romanji or other 
non-ascii-coded roman characters?


They do (e.g. Greek, Cyrillic and there are many other bicameral 
scripts) and there are sometimes special rules. A common example is 
ß->SS, so you can't even be sure of the length! This is locale-dependent 
(e.g. std::toupper listens to the std::locale). This, again, is a "hard" 
problem, and there are libraries for it, e.g. ICU, if you really need to 
get it right (e.g. normalizing Unicode sequences to NFC first, etc).


In any case, the capitalization algorithm is a iteration of the string.


When else do we scan strings?


The question is when do we randomly index into strings without having 
scanned for the index point beforehand. This is actually not a common 
action when you're dealing with arbitrary user input. You will normally 
be using some kind of iterative process like "find the offset of the 
first colon" or "split on the second space" or "uppercase this string" 
or "replace illegal characters" or something.


Things like string sorting will also "just work" in UTF-8. It's designed 
that way so that lexicographically sorting by byte is the same as 
lexicographically sorting by code point[5].


If you're dealing with known or expected text, you can certainly still 
index into a UTF-8/32 string. But never for text that's come from some 
Unicode source. It could be anything, even just 5 zero-width joiners 
in a row and that silly poo emoji at the end. That is a problem for 
HarfBuzz.


Yes, it's extremely annoying, but human language is a very complex thing.

Cheers,

John

[1]: https://bugs.launchpad.net/kicad/+bug/594064 (though I think a 
Hershey Chinese font would be "fun", I don't see it happening soon).

[2]: http://docs.kicad-pcb.org/doxygen/v6_road_map.html#v6_sch_sys_fonts
[3]: https://en.wikipedia.org/wiki/HarfBuzz
[4]: The iPhone SMS of Death was caused by a "nonsense" Unicode code 
point sequence.
[5]: And if you want "real" sorting, well, that's *also* locale 
dependent: in German DIN 5007-1, ö=o, 5007-2, ö=oe, in Swedish, ö is at 
the end, after ä.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

I think we’re a long way from handling Hiragana, Katakana or Kanji.  Probably 
the same for Tamil or Telegu, although I know nothing about them.

So why do we scan strings?  We do it when tokenizing, but all our tokens are 
roman (if not ascii), so that should be OK.

We also do it looking for numbers to increment.  We’d like this to work for 
other languages, but as long as their subsequent-code-points don’t look like 
roman digits I think we’re OK.  (Subsequent-code-points are all above ascii, 
right?).

We do some case conversions when doing compares.  But again, as long as 
subsequent code points don’t look like ascii we should be OK.  I assume 
capitalization algorithms don’t try to do it on Romanji or other 
non-ascii-coded roman characters?

When else do we scan strings?

> On 30 Apr 2019, at 21:35, John Beard  wrote:
> 
> On 30/04/2019 18:19, Jeff Young wrote:
>> I was referring to UCS-2 or UCS-4.  I’m evidently behind the times, though, 
>> because I now see that UTF-32 and UCS-4 are equivalent.
>> (Which means that both some of John’s original premises and my quote in teal 
>> below were wrong: UTF32 is indeed a one:one map between code points and 
>> chars.)
> 
> Kind of, depending the on definition of character. As long as you never get 
> any multi-code point "characters".
> 
>> So my proposal (in 2019) should be std::u32string (using UTF32 encoding, for 
>> which myString[3] still works).
> 
> By "works", what do you mean? Sure you can index into a UTF-32 string and 
> come up with a valid (whole) code point (and a valid code unit). But that 
> doesn't mean a lot: it could be the "ᄀ" (\u1100) from 가, which is actually 2 
> code points.
> 
> How often do we actually index into a string buffer by code point anyway, 
> without iterating the string to find something first? What does that even 
> mean in the context of a Unicode string?
> 
> Graphemes are not a strange and ignorable edge case: emojis may sound silly, 
> but lots of actual languages use grapheme clusters perfectly casually (Tamil, 
> Telegu[1], Hangul as above, etc). You either support Unicode or you don't, 
> you cannot pick and choose what is "reasonable" to support.
> 
> BTW, UTF-8 is does allow you to index into it by byte and see if you're on a 
> code point boundary (if the byte starts 0b10xx, you are not). You can't 
> index to the n'th code point (but for what purpose?) and you still can't 
> index to the n'th grapheme, but you can't do that in *any* encoding.
> 
>> Better?
> 
> As long as we save our files as UTF-8, I don't really mind what we use 
> internally. But if you actually plan to manipulate strings that could be 
> Unicode and it comes from a user, you cannot do it only by code point, 
> regardless of representation.
> 
> Cheers,
> 
> John
> 
> [1]: Mishandling of Telegu produced the iPhone SMS of Death bug.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[John Beard]

On 30/04/2019 18:19, Jeff Young wrote:

I was referring to UCS-2 or UCS-4.  I’m evidently behind the times, though, 
because I now see that UTF-32 and UCS-4 are equivalent.

(Which means that both some of John’s original premises and my quote in teal 
below were wrong: UTF32 is indeed a one:one map between code points and chars.)


Kind of, depending the on definition of character. As long as you never 
get any multi-code point "characters".



So my proposal (in 2019) should be std::u32string (using UTF32 encoding, for 
which myString[3] still works).


By "works", what do you mean? Sure you can index into a UTF-32 string 
and come up with a valid (whole) code point (and a valid code unit). But 
that doesn't mean a lot: it could be the "ᄀ" (\u1100) from 가, which is 
actually 2 code points.


How often do we actually index into a string buffer by code point 
anyway, without iterating the string to find something first? What does 
that even mean in the context of a Unicode string?


Graphemes are not a strange and ignorable edge case: emojis may sound 
silly, but lots of actual languages use grapheme clusters perfectly 
casually (Tamil, Telegu[1], Hangul as above, etc). You either support 
Unicode or you don't, you cannot pick and choose what is "reasonable" to 
support.


BTW, UTF-8 is does allow you to index into it by byte and see if you're 
on a code point boundary (if the byte starts 0b10xx, you are not). 
You can't index to the n'th code point (but for what purpose?) and you 
still can't index to the n'th grapheme, but you can't do that in *any* 
encoding.



Better?


As long as we save our files as UTF-8, I don't really mind what we use 
internally. But if you actually plan to manipulate strings that could be 
Unicode and it comes from a user, you cannot do it only by code point, 
regardless of representation.


Cheers,

John

[1]: Mishandling of Telegu produced the iPhone SMS of Death bug.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eemodern fix compil issue

[Jeff Young]

Hi JP,

Yeah, someone on the forums also found that.  It’s fixed already.

Cheers,
Jeff.


> On 30 Apr 2019, at 19:10, jp charras  wrote:
> 
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] eemodern fix compil issue

[jp charras]

Hi Jeff,

I just compiled eemodern, and I had a compil error.
This patch fixes the error.

-- 
Jean-Pierre CHARRAS
 eeschema/tools/sch_selection_tool.cpp | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/eeschema/tools/sch_selection_tool.cpp 
b/eeschema/tools/sch_selection_tool.cpp
index b7eddca17..ed7142208 100644
--- a/eeschema/tools/sch_selection_tool.cpp
+++ b/eeschema/tools/sch_selection_tool.cpp
@@ -74,7 +74,7 @@ TOOL_ACTION SCH_ACTIONS::removeItemsFromSel( 
"eeschema.InteractiveSelection.Remo
 TOOL_ACTION SCH_ACTIONS::clearSelection( 
"eeschema.InteractiveSelection.ClearSelection",
 AS_GLOBAL, 0, "", "" );// No description, it is not supposed to be 
shown anywhere
 
-
+
 SCH_SELECTION_TOOL::SCH_SELECTION_TOOL() :
 TOOL_INTERACTIVE( "eeschema.InteractiveSelection" ),
 m_frame( nullptr ),
@@ -513,7 +513,8 @@ int SCH_SELECTION_TOOL::SelectNode( const TOOL_EVENT& 
aEvent )
 
 int SCH_SELECTION_TOOL::SelectConnection( const TOOL_EVENT& aEvent )
 {
-RequestSelection( (KICAD_T[]) { SCH_LINE_LOCATE_WIRE_T, 
SCH_LINE_LOCATE_BUS_T, EOT } );
+static KICAD_T candidates[] { SCH_LINE_LOCATE_WIRE_T, 
SCH_LINE_LOCATE_BUS_T, EOT };
+RequestSelection( candidates );
 
 if( m_selection.Empty() )
 return 0;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

I was referring to UCS-2 or UCS-4.  I’m evidently behind the times, though, 
because I now see that UTF-32 and UCS-4 are equivalent.

(Which means that both some of John’s original premises and my quote in teal 
below were wrong: UTF32 is indeed a one:one map between code points and chars.)

So my proposal (in 2019) should be std::u32string (using UTF32 encoding, for 
which myString[3] still works).

Better?

Cheers,
Jeff.

PS: I was last in deep with this stuff during the early days of PDF & Acrobat — 
which was 30 years ago. ;)


> On 30 Apr 2019, at 18:05, Seth Hillbrand  wrote:
> 
> Am 2019-04-30 12:49, schrieb Jeff Young:
> 
>> You are correct that you also can’t do it with UTF32 strings, but
>> I’m not suggesting those.  I’m suggesting *unicode* strings.
>> That’s 1 code-point per character.  So myString[3] still works.
> 
> Sorry Jeff, I'm being slow here and must be missing an important point.  I 
> had thought that unicode was encoded by UTF-8, UTF-16, etc.  But it sounds 
> like you a referring to something different.  Is there a good place to look 
> for more information on the specific encoding you are suggesting?
> 
> -Seth


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Seth Hillbrand]

Am 2019-04-30 12:49, schrieb Jeff Young:


You are correct that you also can’t do it with UTF32 strings, but
I’m not suggesting those.  I’m suggesting *unicode* strings.
That’s 1 code-point per character.  So myString[3] still works.


Sorry Jeff, I'm being slow here and must be missing an important point.  
I had thought that unicode was encoded by UTF-8, UTF-16, etc.  But it 
sounds like you a referring to something different.  Is there a good 
place to look for more information on the specific encoding you are 
suggesting?


-Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

Thanks for the analysis, John.  However, those numbers are with wxWidget’s 
performance optimizations (the ones that crash when multi-threaded), so we 
don’t really know how bad they would be without it.

Also, wxString hides the UTF8 serialization from us and makes for simpler code. 
 You can use myString[3] and get the 3rd character.  You can’t do that with 
UTF8 strings.

You are correct that you also can’t do it with UTF32 strings, but I’m not 
suggesting those.  I’m suggesting *unicode* strings.  That’s 1 code-point per 
character.  So myString[3] still works. 

(I don’t think graphemes, ligatures, extended-code-points, etc. are a real 
problem for us.  Heck, our stroke font doesn’t even support 10% of unicode.)

Cheers,
Jeff.

Note: if there’s a std::string library that hides the UTF8 serialization from 
us I could be talked into using that.  I do agree that it looks like the 
performance wouldn’t be a deal-breaker.


> On 30 Apr 2019, at 17:22, John Beard  wrote:
> 
> On 30/04/2019 16:01, Jeff Young wrote:
>> Primarily for performance reasons.
> 
> WRT performance, I did a few benchmarks for reference (on Linux)
> 
> Loading this large CIAA PCB[1] allocates, out of a peak usage of 467MB of 
> heap with a 0.01% threshold:
> 
> * 9.6MB of std::basic_string::_M_assign
>   * 9.4MB of this is from wxString operator= assignments
> * ~600kB of std::basic_string::_M_construct, (wxString ctor)
> 
> So I'm not sure memory usage is a major factor to worry about (strings 
> allocate storage on the heap, so we should see basically all the interesting 
> things in the heap profile). UTF-8 could be as little as 1/4 UTF-32 (all 
> strings are ASCII), but even then, it's a few MB saved.
> 
> Now, in terms of performance, opening Pcbnew with no file gives:
> 
> #4  3.36% __gconv_transform_utf8_internal 
> #5  2.51%   __mbsrtowcs_l
> #6  2.50%   wxMBConv::ToWChar
> #8  2.07%   std::basic_string::_M_assign
> #9  1.88%   wxMBConvStrictUTF8::ToWChar
> #14 1.27%   EscapeString (kicad function)
> #17 0.85%   __GI___strlen_sse2  #18 0.85%  
> wxUniChar::From8bit 
> #19 0.84%  wxUniChar::operator==
> 
> And plenty more string-y things in the top 50 or so lines. So it seems the 
> biggest cost for strings is converting them from UTF-8 to wchar_t strings in 
> WX (this is probably not the same on Windows). But it's not really a stunning 
> cost.
> 
> However, loading the CIAA board, and there are basically no string operations 
> above 0.5%, and only a handful even above 0.25%. When doing DRC, strings 
> don't break 0.1%: nearly all the significant work is looking things up in 
> std::maps and geometry.
> 
> So string performance doesn't seem to be *that* critical, as it's quickly 
> drowned out under real workloads. It looks to me (and I'm happy to be 
> corrected, I'm not a perf expert), like string operations in KiCad are not 
> much of a bottleneck.
> 
> > Because characters are different lengths, you have to scan the string
> > to find the n’th character.
> 
> Even with UTF-32, you can only do an O(1) lookup of the n'th *code point* or 
> *code unit* (the same in UTF-32, not in UTF-8), not the n'th *encoded 
> character*.
> 
> That's true even if you normalise the strings first. Not all code points map 
> one-to-one to an encoded character (it can be one-to-none, one-to-one, 
> many-to-one). And that's even without considering grapheme clustering.
> 
> Cheers,
> 
> John
> 
> PS / OT: If we had to optimise one thing, 
> PolygonTriangulation::Vertex::inTriangle is the single hungriest function, 
> chewing 6.19% of all CPU time, double that of each of the next 3: 
> __gnu_cxx::__exchange_and_add (2.76%),  PolygonTriangulation::isEar (2.73%) 
> and even malloc (2.27%).
> 
> Other than that fairly mundane 6%-er, there are no eye-popping performance 
> hogs simply on loading a PCB. Which is nice.
> 
> [1]: 
> https://github.com/ciaa/Hardware/blob/master/PCB/ACC/CIAA_ACC/ciaa_acc.kicad_pcb

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Seth Hillbrand]

Am 2019-04-30 12:22, schrieb John Beard:

Even with UTF-32, you can only do an O(1) lookup of the n'th *code
point* or *code unit* (the same in UTF-32, not in UTF-8), not the n'th
*encoded character*.


+1 here.  I'd be in favor of standardizing on a clean, 
standards-compliant string library for internal work, converting to 
wxString only for user interaction.


My main beef with UTF-16 (and UTF-32) is that they don't display as 
human readable files without a UTF-16/UTF-32 compatible viewer.  All of 
our file formatting is ASCII with the exception of user-generated 
content.  So, right now, I can use any text viewer to read the files.  
Using UTF-8 preserves this ability but we'd lose this with u32string 
(unless we convert back for writing)


There are some other, minor issues including byte-order marking, 
corruption re-syncronization and external library support that we'd need 
to think closely about if we wanted to change.



PS / OT: If we had to optimise one thing,
PolygonTriangulation::Vertex::inTriangle is the single hungriest
function, chewing 6.19% of all CPU time, double that of each of the
next 3: __gnu_cxx::__exchange_and_add (2.76%),
PolygonTriangulation::isEar (2.73%) and even malloc (2.27%).


FYI, I am currently working on modifying the triangulation.

-Seth

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[John Beard]

On 30/04/2019 16:01, Jeff Young wrote:

Primarily for performance reasons.


WRT performance, I did a few benchmarks for reference (on Linux)

Loading this large CIAA PCB[1] allocates, out of a peak usage of 467MB 
of heap with a 0.01% threshold:


* 9.6MB of std::basic_string::_M_assign
   * 9.4MB of this is from wxString operator= assignments
* ~600kB of std::basic_string::_M_construct, (wxString ctor)

So I'm not sure memory usage is a major factor to worry about (strings 
allocate storage on the heap, so we should see basically all the 
interesting things in the heap profile). UTF-8 could be as little as 1/4 
UTF-32 (all strings are ASCII), but even then, it's a few MB saved.


Now, in terms of performance, opening Pcbnew with no file gives:

#4  3.36%   __gconv_transform_utf8_internal 
#5  2.51%   __mbsrtowcs_l
#6  2.50%   wxMBConv::ToWChar
#8  2.07%   std::basic_string::_M_assign
#9  1.88%   wxMBConvStrictUTF8::ToWChar
#14 1.27%   EscapeString (kicad function)
#17 0.85%   __GI___strlen_sse2 

 #18 0.85%  wxUniChar::From8bit 



#19 0.84%  wxUniChar::operator==

And plenty more string-y things in the top 50 or so lines. So it seems 
the biggest cost for strings is converting them from UTF-8 to wchar_t 
strings in WX (this is probably not the same on Windows). But it's not 
really a stunning cost.


However, loading the CIAA board, and there are basically no string 
operations above 0.5%, and only a handful even above 0.25%. When doing 
DRC, strings don't break 0.1%: nearly all the significant work is 
looking things up in std::maps and geometry.


So string performance doesn't seem to be *that* critical, as it's 
quickly drowned out under real workloads. It looks to me (and I'm happy 
to be corrected, I'm not a perf expert), like string operations in KiCad 
are not much of a bottleneck.


> Because characters are different lengths, you have to scan the string
> to find the n’th character.

Even with UTF-32, you can only do an O(1) lookup of the n'th *code 
point* or *code unit* (the same in UTF-32, not in UTF-8), not the n'th 
*encoded character*.


That's true even if you normalise the strings first. Not all code points 
map one-to-one to an encoded character (it can be one-to-none, 
one-to-one, many-to-one). And that's even without considering grapheme 
clustering.


Cheers,

John

PS / OT: If we had to optimise one thing, 
PolygonTriangulation::Vertex::inTriangle is the single hungriest 
function, chewing 6.19% of all CPU time, double that of each of the next 
3: __gnu_cxx::__exchange_and_add (2.76%),  PolygonTriangulation::isEar 
(2.73%) and even malloc (2.27%).


Other than that fairly mundane 6%-er, there are no eye-popping 
performance hogs simply on loading a PCB. Which is nice.


[1]: 
https://github.com/ciaa/Hardware/blob/master/PCB/ACC/CIAA_ACC/ciaa_acc.kicad_pcb


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kudos to Michael Kavanagh

[Michael Kavanagh]

That’s what I like to hear.

Cheers,
Michael

On Tue, 30 Apr 2019 at 15:39, Maciej Suminski 
wrote:

> On 4/29/19 8:51 PM, Seth Hillbrand wrote:> Orson and I were discussing
> giving Janitor the power to cleanup all bugs
> > with Fix Committed prior to v5.1 as Fix Released.  That should take care
> > of the majority.
> >
> > -S
>
> I am still traveling, but I am sure I will find some spare time to do
> this soon. Do not spend time on a task that can be automated.
>
> Cheers,
> Orson
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

Primarily for performance reasons.  Because characters are different lengths, 
you have to scan the string to find the n’th character.

(wxString solves this with cached iterators, but they’re not thread-safe and so 
we get random crashes from them.)

> On 30 Apr 2019, at 15:59, Dmitry Salychev  wrote:
> 
> On Tue, Apr 30, 2019 at 08:59:46AM -0400, Wayne Stambaugh wrote:
>> Given that std::wstring is platform dependent, I would be opposed to
>> using it.  I'm not opposed to std::u32string but UTF8 is pretty well
>> vetted so please keep that in mind.  I think the possibility of breakage
>> is low but I'm not naive enough to think that it's zero.  You would have
>> to do some serious testing to ensure the conversion of std::u32string to
>> and from UTF8 isn't broken before I would be comfortable merging it into
>> master.
>> 
>> Wayne
>> 
> These are just thoughts of a stranger.
> 
> Why not to use std::string to keep a byte array which represents a UTF-8
> string itself? Size of the string means its length in bytes and
> utf8::distance() [1] returns a number of the code points, i.e.
> length in symbols.
> 
> [1] http://utfcpp.sourceforge.net/
> 
> Regards,
> Dmitry
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Dmitry Salychev]

On Tue, Apr 30, 2019 at 08:59:46AM -0400, Wayne Stambaugh wrote:
> Given that std::wstring is platform dependent, I would be opposed to
> using it.  I'm not opposed to std::u32string but UTF8 is pretty well
> vetted so please keep that in mind.  I think the possibility of breakage
> is low but I'm not naive enough to think that it's zero.  You would have
> to do some serious testing to ensure the conversion of std::u32string to
> and from UTF8 isn't broken before I would be comfortable merging it into
> master.
> 
> Wayne
> 
These are just thoughts of a stranger.

Why not to use std::string to keep a byte array which represents a UTF-8
string itself? Size of the string means its length in bytes and
utf8::distance() [1] returns a number of the code points, i.e.
length in symbols.

[1] http://utfcpp.sourceforge.net/

Regards,
Dmitry

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kudos to Michael Kavanagh

[Maciej Suminski]

On 4/29/19 8:51 PM, Seth Hillbrand wrote:> Orson and I were discussing
giving Janitor the power to cleanup all bugs
> with Fix Committed prior to v5.1 as Fix Released.  That should take care
> of the majority.
> 
> -S

I am still traveling, but I am sure I will find some spare time to do
this soon. Do not spend time on a task that can be automated.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

The GUI is strongly bound to wxWidgets anyway, so I don’t have an issue using 
wxString there.  Although I’m sure we could create our own “_()” macro at some 
point if it comes to that.

> On 30 Apr 2019, at 14:55, Wayne Stambaugh  wrote:
> 
> What about translated strings?  Is changing them from wxString to
> u32string going to be an issue?  I know this doesn't effect the file I/O
> strings but it is something we are going to have to consider if we are
> going to punt wxString.
> 
> On 4/30/19 9:27 AM, Jeff Young wrote:
>> Sure, but we’re going to be re-writing the parsers and formatters for
>> s-expr so it’s going to be all different code anyway.  (Granted the new
>> code could have used the old infrastructure, but I think we need to wean
>> ourselves from wxString either way.)
>> 
>>> On 30 Apr 2019, at 13:59, Wayne Stambaugh >> > wrote:
>>> 
>>> Given that std::wstring is platform dependent, I would be opposed to
>>> using it.  I'm not opposed to std::u32string but UTF8 is pretty well
>>> vetted so please keep that in mind.  I think the possibility of breakage
>>> is low but I'm not naive enough to think that it's zero.  You would have
>>> to do some serious testing to ensure the conversion of std::u32string to
>>> and from UTF8 isn't broken before I would be comfortable merging it into
>>> master.
>>> 
>>> Wayne
>>> 
>>> On 4/30/19 7:32 AM, Jeff Young wrote:
 I suspect all our platforms use at least 32 bit ints, but even so
 std::u32string does communicate the intent better.
 
 So change the proposal to that….
 
 Cheers,
 Jeff.
 
> On 30 Apr 2019, at 10:52, Andrew Lutsenko  
> > wrote:
> 
> Hi,
> I have no opinion on the matter but would add a reminder that wchar_t
> is platform and compiler dependent.
> Consider using std::u32string instead of std::wstring if you want all
> code points to fit into one element.
> 
> Regards,
> Andrew
> 
> On Tue, Apr 30, 2019 at 2: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
>flexibility.)
> 
>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.)
>___
>Mailing list: https://launchpad.net/~kicad-developers
>Post to : kicad-developers@lists.launchpad.net
> 
>
>Unsubscribe : https://launchpad.net/~kicad-developers
>More help   : https://help.launchpad.net/ListHelp
> 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Wayne Stambaugh]

What about translated strings?  Is changing them from wxString to
u32string going to be an issue?  I know this doesn't effect the file I/O
strings but it is something we are going to have to consider if we are
going to punt wxString.

On 4/30/19 9:27 AM, Jeff Young wrote:
> Sure, but we’re going to be re-writing the parsers and formatters for
> s-expr so it’s going to be all different code anyway.  (Granted the new
> code could have used the old infrastructure, but I think we need to wean
> ourselves from wxString either way.)
> 
>> On 30 Apr 2019, at 13:59, Wayne Stambaugh > > wrote:
>>
>> Given that std::wstring is platform dependent, I would be opposed to
>> using it.  I'm not opposed to std::u32string but UTF8 is pretty well
>> vetted so please keep that in mind.  I think the possibility of breakage
>> is low but I'm not naive enough to think that it's zero.  You would have
>> to do some serious testing to ensure the conversion of std::u32string to
>> and from UTF8 isn't broken before I would be comfortable merging it into
>> master.
>>
>> Wayne
>>
>> On 4/30/19 7:32 AM, Jeff Young wrote:
>>> I suspect all our platforms use at least 32 bit ints, but even so
>>> std::u32string does communicate the intent better.
>>>
>>> So change the proposal to that….
>>>
>>> Cheers,
>>> Jeff.
>>>
 On 30 Apr 2019, at 10:52, Andrew Lutsenko >>> 
 > wrote:

 Hi,
 I have no opinion on the matter but would add a reminder that wchar_t
 is platform and compiler dependent.
 Consider using std::u32string instead of std::wstring if you want all
 code points to fit into one element.

 Regards,
 Andrew

 On Tue, Apr 30, 2019 at 2: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
    flexibility.)

    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.)
    ___
    Mailing list: https://launchpad.net/~kicad-developers
    Post to     : kicad-developers@lists.launchpad.net
 
    
    Unsubscribe : https://launchpad.net/~kicad-developers
    More help   : https://help.launchpad.net/ListHelp

>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Modern toolset usability improvements

[Jeff Young]

If you have no selection then HK_DELETE will pick whatever is under the cursor 
(whether a wire or not) and delete it.

If you do have a selection HK_DELETE will delete that.  We can’t pay attention 
to hover when there’s a selection.  (Well, unless we want to use eye-tracking 
from the screen-facing camera….)

> On 30 Apr 2019, at 14:30, Wayne Stambaugh  wrote:
> 
> When the wire tool is active and not in the process of drawing a wire,
> what happens when you hit backspace or delete when hovering over an
> unselected wire?  I don't want the current behavior for this to be lost.
> 
> On 4/30/19 9:10 AM, Jeff Young wrote:
>> Hi Wayne,
>> 
>> No, to delete a node you’d do a HK_SELECT_NODE and then backspace.  To 
>> delete a whole connection you’d do a HK_SELECT_CONNECTION and then a 
>> backspace.
>> 
>> Note that in 5.1 there’s no hotkey for delete connection, so one had to use 
>> the context menu for that.  That was much more cumbersome.
>> 
>> 5.1 does have a hotkey for delete node, but on OSX at least it steals the 
>> delete key from other things, so users have to disable (or reassign) it 
>> anyway.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 30 Apr 2019, at 14:06, Wayne Stambaugh  wrote:
>>> 
>>> Just so I understand what you are proposing, backspace will remove a
>>> wire node (segment) and delete will remove the entire net.  The legacy
>>> behavior was very convenient so we should think carefully before
>>> changing it.
>>> 
>>> On 4/30/19 7:49 AM, Jeff Young wrote:
 For the most part the modern toolset encourages a noun/verb pattern 
 (select, perform-operation).  I’m not going to be pedantic about that 
 because some commands such as Edit Value and Edit Reference are too useful 
 (they’re nominally verbs but also acts as nouns when there is no existing 
 selection).
 
 However, I am moving Delete Node and Delete Connection to a noun/verb 
 pattern.  So they’ll be replaced with Select Node and Select Connection, 
 and then the normal  action can be used to delete them.
 
 This also allows me to improve editing with the Wire or Bus tool active: 
 you can use the Select Node and Select Connection hotkeys to select wires 
 (and potentially delete them) without exiting the tool.  And when/if 
 wires/busses get a Properties dialog you’ll also be able to edit them 
 without leaving the bus or wire tool.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Modern toolset usability improvements

[Wayne Stambaugh]

When the wire tool is active and not in the process of drawing a wire,
what happens when you hit backspace or delete when hovering over an
unselected wire?  I don't want the current behavior for this to be lost.

On 4/30/19 9:10 AM, Jeff Young wrote:
> Hi Wayne,
> 
> No, to delete a node you’d do a HK_SELECT_NODE and then backspace.  To delete 
> a whole connection you’d do a HK_SELECT_CONNECTION and then a backspace.
> 
> Note that in 5.1 there’s no hotkey for delete connection, so one had to use 
> the context menu for that.  That was much more cumbersome.
> 
> 5.1 does have a hotkey for delete node, but on OSX at least it steals the 
> delete key from other things, so users have to disable (or reassign) it 
> anyway.
> 
> Cheers,
> Jeff.
> 
> 
>> On 30 Apr 2019, at 14:06, Wayne Stambaugh  wrote:
>>
>> Just so I understand what you are proposing, backspace will remove a
>> wire node (segment) and delete will remove the entire net.  The legacy
>> behavior was very convenient so we should think carefully before
>> changing it.
>>
>> On 4/30/19 7:49 AM, Jeff Young wrote:
>>> For the most part the modern toolset encourages a noun/verb pattern 
>>> (select, perform-operation).  I’m not going to be pedantic about that 
>>> because some commands such as Edit Value and Edit Reference are too useful 
>>> (they’re nominally verbs but also acts as nouns when there is no existing 
>>> selection).
>>>
>>> However, I am moving Delete Node and Delete Connection to a noun/verb 
>>> pattern.  So they’ll be replaced with Select Node and Select Connection, 
>>> and then the normal  action can be used to delete them.
>>>
>>> This also allows me to improve editing with the Wire or Bus tool active: 
>>> you can use the Select Node and Select Connection hotkeys to select wires 
>>> (and potentially delete them) without exiting the tool.  And when/if 
>>> wires/busses get a Properties dialog you’ll also be able to edit them 
>>> without leaving the bus or wire tool.
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

Sure, but we’re going to be re-writing the parsers and formatters for s-expr so 
it’s going to be all different code anyway.  (Granted the new code could have 
used the old infrastructure, but I think we need to wean ourselves from 
wxString either way.)

> On 30 Apr 2019, at 13:59, Wayne Stambaugh  wrote:
> 
> Given that std::wstring is platform dependent, I would be opposed to
> using it.  I'm not opposed to std::u32string but UTF8 is pretty well
> vetted so please keep that in mind.  I think the possibility of breakage
> is low but I'm not naive enough to think that it's zero.  You would have
> to do some serious testing to ensure the conversion of std::u32string to
> and from UTF8 isn't broken before I would be comfortable merging it into
> master.
> 
> Wayne
> 
> On 4/30/19 7:32 AM, Jeff Young wrote:
>> I suspect all our platforms use at least 32 bit ints, but even so
>> std::u32string does communicate the intent better.
>> 
>> So change the proposal to that….
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 30 Apr 2019, at 10:52, Andrew Lutsenko >> 
>>> >> wrote:
>>> 
>>> Hi,
>>> I have no opinion on the matter but would add a reminder that wchar_t
>>> is platform and compiler dependent.
>>> Consider using std::u32string instead of std::wstring if you want all
>>> code points to fit into one element.
>>> 
>>> Regards,
>>> Andrew
>>> 
>>> On Tue, Apr 30, 2019 at 2: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
>>>flexibility.)
>>> 
>>>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.)
>>>___
>>>Mailing list: https://launchpad.net/~kicad-developers 
>>> 
>>>Post to : kicad-developers@lists.launchpad.net 
>>> 
>>>>> >
>>>Unsubscribe : https://launchpad.net/~kicad-developers 
>>> 
>>>More help   : https://help.launchpad.net/ListHelp 
>>> 
>>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Modern toolset usability improvements

[Jeff Young]

Hi Wayne,

No, to delete a node you’d do a HK_SELECT_NODE and then backspace.  To delete a 
whole connection you’d do a HK_SELECT_CONNECTION and then a backspace.

Note that in 5.1 there’s no hotkey for delete connection, so one had to use the 
context menu for that.  That was much more cumbersome.

5.1 does have a hotkey for delete node, but on OSX at least it steals the 
delete key from other things, so users have to disable (or reassign) it anyway.

Cheers,
Jeff.


> On 30 Apr 2019, at 14:06, Wayne Stambaugh  wrote:
> 
> Just so I understand what you are proposing, backspace will remove a
> wire node (segment) and delete will remove the entire net.  The legacy
> behavior was very convenient so we should think carefully before
> changing it.
> 
> On 4/30/19 7:49 AM, Jeff Young wrote:
>> For the most part the modern toolset encourages a noun/verb pattern (select, 
>> perform-operation).  I’m not going to be pedantic about that because some 
>> commands such as Edit Value and Edit Reference are too useful (they’re 
>> nominally verbs but also acts as nouns when there is no existing selection).
>> 
>> However, I am moving Delete Node and Delete Connection to a noun/verb 
>> pattern.  So they’ll be replaced with Select Node and Select Connection, and 
>> then the normal  action can be used to delete them.
>> 
>> This also allows me to improve editing with the Wire or Bus tool active: you 
>> can use the Select Node and Select Connection hotkeys to select wires (and 
>> potentially delete them) without exiting the tool.  And when/if wires/busses 
>> get a Properties dialog you’ll also be able to edit them without leaving the 
>> bus or wire tool.
>> 
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Modern toolset usability improvements

[Wayne Stambaugh]

Just so I understand what you are proposing, backspace will remove a
wire node (segment) and delete will remove the entire net.  The legacy
behavior was very convenient so we should think carefully before
changing it.

On 4/30/19 7:49 AM, Jeff Young wrote:
> For the most part the modern toolset encourages a noun/verb pattern (select, 
> perform-operation).  I’m not going to be pedantic about that because some 
> commands such as Edit Value and Edit Reference are too useful (they’re 
> nominally verbs but also acts as nouns when there is no existing selection).
> 
> However, I am moving Delete Node and Delete Connection to a noun/verb 
> pattern.  So they’ll be replaced with Select Node and Select Connection, and 
> then the normal  action can be used to delete them.
> 
> This also allows me to improve editing with the Wire or Bus tool active: you 
> can use the Select Node and Select Connection hotkeys to select wires (and 
> potentially delete them) without exiting the tool.  And when/if wires/busses 
> get a Properties dialog you’ll also be able to edit them without leaving the 
> bus or wire tool.
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Improving library editor checks

[Antonio Vázquez Blanco]

Maybe starting with footprint checking improvements is easier as python
scripting support seems more advanced and that would allow me to start
working on something. AFAIK there is SWIG for that part (I do not know how
stable it is but I am willing to cope with that). ¿What do you think about
that?

As pointed by users in the forum it would be interesting to be able to run
the check scripts from command line in order to integrate the checks into
Travis/Gitlab or whatever CI environment is going to be used. Also, current
check scripts implement their own parsing which I would like to avoid by
using KiCad implementation.

Thank you!

El jue., 25 abr. 2019 a las 16:15, Wayne Stambaugh ()
escribió:

> Python scripting support is hopefully going to be implemented at some
> point during V6 development.  This should allow you to integrate the KLC
> scripts directly into the symbol library editor.  This will most likely
> happen late in V6 development because there are some major functional
> changes to the low level schematic and library objects.  It doesn't make
> sense to swig this until the low level object APIs stabilize.
>
> On 4/25/19 9:39 AM, Antonio Vázquez Blanco wrote:
> > From the feedback given I am thinking about changing the proposal.
> >
> > Given that my ultimate goal was to integrate KLC check into KiCad to
> > improve the quality of contributions and reduce librarian work, and that
> > seems conflicting we may need to re-think my approach to the problem.
> >
> > I don't want to enforce KLC on every user. Furthermore, from your
> > comments I thought that maybe I am interested in even writing some tests
> > that would conform with a set of rules that only my organization would
> > care about. That being said, I came to the conclusion that maybe we
> > could define groups of tests that could be enabled or disabled depending
> > on user preferences. For example, KLC could be one of those groups of
> rules.
> >
> > John suggested the usage of external scripts. That could be the solution
> > to various problems. Scripts could be externally updated if needed and
> > they would also allow to users to write their own checks without having
> > to recompille the full source code. It would also allow the distribution
> > of those "groups" of rules suggested above.
> >
> > Maybe we sould think of a interface that would allow KiCad to look for a
> > set of Python scripts inside a particular folder to allow us to perform
> > a certain set of checks that would return result objects that KiCad
> > could later show.
> >
> > Is this approach better? If so, given my lack of knowledge about KiCad
> > codebase, I would need some help designing that interface.
> >
> > Thank you for your feedback!
> >
> >
> >
> >
> >
> >
> > El jue., 25 abr. 2019 a las 13:46, Wayne Stambaugh
> > (mailto:stambau...@gmail.com>>) escribió:
> >
> > Antonio,
> >
> > Exactly what checks are you planning on implementing?  As long as
> they
> > are generic in nature like off grid pin checking, then I'm fine with
> > that.  If they are specific KLC checks like spacing, line width, etc,
> > that is a different issue.  We should not be forcing KLC rules on all
> > users.  If you wanted to make KLC style checks that can be customized
> > and disabled to meet each users specific needs, I would be open to
> that.
> >
> > This code is not in the ERC code.  Symbol library tests are separate
> > from the ERC and live in the symbol editor code.  You can find the
> > symbol library editor code in the ./eeschema/libedit folder in the
> > source tree.
> >
> > Thank you in your interest in contributing to KiCad.
> >
> > Cheers,
> >
> > Wayne
> >
> > On 4/25/19 5:39 AM, Antonio Vázquez Blanco wrote:
> > > I've been playing around a little bit with KiCad source code
> > lately and
> > > in the forums [1] I was encouraged to write to the dev mailing
> list in
> > > order to get feedback on how to improve the current library error
> > checking.
> > >
> > > Summarizing the thread, I made some changes [2] so that a couple
> > of KLC
> > > checks are performed on syms but now that I've done that I would
> > like to
> > > implement this properly. I am looking for pointers on how should I
> > > implement this so that the chances of me getting the code upstream
> > > maximize and so that I can reuse the ERC/DRC code as much as
> possible.
> > >
> > > Thank you!
> > >
> > > [1]
> https://forum.kicad.info/t/improving-library-editor-checks/16557/5
> > > [2]
> > >
> >
> https://gitlab.com/kicad-mirror/kicad-source-mirror/compare/master...feature%2Fklc
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > 
> > > Unsubscribe : https://launchpad.ne

Re: [Kicad-developers] 6.0 string proposal

[Wayne Stambaugh]

Given that std::wstring is platform dependent, I would be opposed to
using it.  I'm not opposed to std::u32string but UTF8 is pretty well
vetted so please keep that in mind.  I think the possibility of breakage
is low but I'm not naive enough to think that it's zero.  You would have
to do some serious testing to ensure the conversion of std::u32string to
and from UTF8 isn't broken before I would be comfortable merging it into
master.

Wayne

On 4/30/19 7:32 AM, Jeff Young wrote:
> I suspect all our platforms use at least 32 bit ints, but even so
> std::u32string does communicate the intent better.
> 
> So change the proposal to that….
> 
> Cheers,
> Jeff.
> 
>> On 30 Apr 2019, at 10:52, Andrew Lutsenko > > wrote:
>>
>> Hi,
>> I have no opinion on the matter but would add a reminder that wchar_t
>> is platform and compiler dependent.
>> Consider using std::u32string instead of std::wstring if you want all
>> code points to fit into one element.
>>
>> Regards,
>> Andrew
>>
>> On Tue, Apr 30, 2019 at 2: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
>> flexibility.)
>>
>> 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.)
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Modern toolset usability improvements

[Jeff Young]

For the most part the modern toolset encourages a noun/verb pattern (select, 
perform-operation).  I’m not going to be pedantic about that because some 
commands such as Edit Value and Edit Reference are too useful (they’re 
nominally verbs but also acts as nouns when there is no existing selection).

However, I am moving Delete Node and Delete Connection to a noun/verb pattern.  
So they’ll be replaced with Select Node and Select Connection, and then the 
normal  action can be used to delete them.

This also allows me to improve editing with the Wire or Bus tool active: you 
can use the Select Node and Select Connection hotkeys to select wires (and 
potentially delete them) without exiting the tool.  And when/if wires/busses 
get a Properties dialog you’ll also be able to edit them without leaving the 
bus or wire tool.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Jeff Young]

I suspect all our platforms use at least 32 bit ints, but even so 
std::u32string does communicate the intent better.

So change the proposal to that….

Cheers,
Jeff.

> On 30 Apr 2019, at 10:52, Andrew Lutsenko  wrote:
> 
> Hi,
> I have no opinion on the matter but would add a reminder that wchar_t is 
> platform and compiler dependent.
> Consider using std::u32string instead of std::wstring if you want all code 
> points to fit into one element.
> 
> Regards,
> Andrew
> 
> On Tue, Apr 30, 2019 at 2: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 flexibility.)
> 
> 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.)
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Thomas Pointhuber]

Hi,

 

I would like to drop in this website to the discussion: https://utf8everywhere.org/

 

There are good points, and I would suggest either storing them internally with 8 or 32 bit.

 

Regards, Thomas

 

 

Gesendet: Dienstag, 30. April 2019 um 11:52 Uhr
Von: "Andrew Lutsenko" 
An: "Jeff Young" 
Cc: "KiCad Developers" 
Betreff: Re: [Kicad-developers] 6.0 string proposal



Hi,
I have no opinion on the matter but would add a reminder that wchar_t is platform and compiler dependent.

Consider using std::u32string instead of std::wstring if you want all code points to fit into one element.
 

Regards,

Andrew


 


On Tue, Apr 30, 2019 at 2: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 flexibility.)

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.)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 6.0 string proposal

[Andrew Lutsenko]

Hi,
I have no opinion on the matter but would add a reminder that wchar_t is
platform and compiler dependent.
Consider using std::u32string instead of std::wstring if you want all code
points to fit into one element.

Regards,
Andrew

On Tue, Apr 30, 2019 at 2: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 flexibility.)
>
> 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.)
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] 6.0 string proposal

[Jeff Young]

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 flexibility.)

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.)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] GLM 0.9.9.3 and GLM_FORCE_PURE

[Mário Luzeiro]

> - detecting broken GLM at configure time, setting GLM_FORCE_PURE globally 
> there

> might cause two different build configurations with different bugs, so
> it will make debugging harder, but at least compiling from source works
> for everyone

I vote for that one.
I feel there won't be any issued caused by GLM using intrinsics, in any case, 
that will be only closed to 3D related stuff.

Regarding the performance,
The best performance using SIMD is achieve when the implementation is 
cache-friendly and data batch processed - that is not the case of 3D Viewer.
So the possible minimal impact will be on internal GLM functions (eg matrix, 
etc) or related with some compiler time optimization...
I would say for the use 3D Viewer is using it (the possible intrinsics 
optimization), it may be unnoticeable for the user perspective.

Mario


From: Simon Richter 
Sent: 30 April 2019 00:54
To: Mário Luzeiro; kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] GLM 0.9.9.3 and GLM_FORCE_PURE

Hi Mário,

On 29.04.19 23:49, Mário Luzeiro wrote:

> I was checking the commit, it is a commit by Cirilo from some of my 
> indications for includes and he copied the file at that state.
> I checked my log where that changes come from and there was also noting 
> useful there.
> So it may was some test or something else at that moment.
> I hope SIMD performs better, but it can also be profiled.

I've asked the compiler and performance geeks on Twitter a kind of
backhanded question on the performance impact:

https://twitter.com/GyrosGeier/status/1122945918565867521

In summary, "it's complicated."

>From a performance point of view, scalarizing everything and then
autovectorizing after loop unrolling is way better than trusting the
programmer on vectorization, and GLM using intrinsics forces operands
into xmm registers in a particular layout, which then in turn requires
gcc to use vector instructions matching that layout or shuffling them
around.

vec3 is particularly unsuitable for xmm instructions, because there is
no three-element dot product, a quarter of the lanes goes unused all the
time but still impacts performance if it goes denormal or encounters a
domain error.

Intel's OpenCL implementation for GPUs begins with a scalarize pass for
precisely that reason, I expect others to do that as well ­— but OpenCL
is special in that the topmost loop is external to the compiled code,
which is a luxury we don't have.

So I guess we need to profile this to make a good decision, but we also
need to be able to offer something to people compiling from source on
Debian buster.

> I found also this on the mailing list that may be helpful for you:
> https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg32827.html

Yes, that is consistent with the current thread. C++11's constexpr is
slightly different from C++14's, and GLM not taking this into account is
a GLM bug, which they've fixed in later versions, and the fix has also
been backported to Debian buster, so they have a 0.9.9.3 version that
works, which means our current test is too strict.

Avenues I could see:

 - the patch as is

unclear performance impact, might be positive or negative or most likely
irrelevant

 - switching to C++14

likely no performance impact, also avoids the problem

 - detecting broken GLM at configure time, rejecting

the minimal change

 - detecting broken GLM at configure time, setting GLM_FORCE_PURE
globally there

might cause two different build configurations with different bugs, so
it will make debugging harder, but at least compiling from source works
for everyone

 - repeatedly explaining to people how to update their GLM if kicad
fails to configure

in Brexit terms, the "no-deal" option

   Simon


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp