[Kicad-developers] SCH_ITEM::Draw()

These routines are only used for printing now, correct? I’ve got a changelist which removes the code supporting interactive features in them (such as brightening and dragging), but I just want to make sure before I commit it. Cheers, Jeff. ___

Re: [Kicad-developers] Git down?

Ditto. On 4/3/2019 3:28 PM, Jon Evans wrote: > Same for me > > On Wed, Apr 3, 2019 at 3:27 PM Jeff Young > wrote: > > Is launchpad’s git instance down?  It’s refusing my connection... > ___ > Mailing list:

Re: [Kicad-developers] Git down?

See https://twitter.com/launchpadstatus/status/1113042990228963328 On Wed, 3 Apr 2019 at 21:28, Jon Evans wrote: > Same for me > > On Wed, Apr 3, 2019 at 3:27 PM Jeff Young wrote: > >> Is launchpad’s git instance down? It’s refusing my connection... >>

Re: [Kicad-developers] Git down?

Same for me On Wed, Apr 3, 2019 at 3:27 PM Jeff Young wrote: > Is launchpad’s git instance down? It’s refusing my connection... > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net >

[Kicad-developers] Git down?

Is launchpad’s git instance down? It’s refusing my connection... ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help :

Re: [Kicad-developers] Failing tests

I suspect I have just fixed these. There were a couple of places where we returned a const-reference to a function result which is no longer const-reference. > On 3 Apr 2019, at 18:47, Simon Richter wrote: > > Hi, > > Jenkins reports failing tests on Linux since commit 5ac96c612 "More >

Re: [Kicad-developers] Bus upgrades merge

I can move to stdlib regex; I'll look in to that later this week. On Wed, Apr 3, 2019 at 1:44 PM Wayne Stambaugh wrote: > Tom, > > On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote: > > On 02/04/2019 17:27, Wayne Stambaugh wrote: > >> We should always be using wxLogTrace. Using printf and cout are

[Kicad-developers] Failing tests

Hi, Jenkins reports failing tests on Linux since commit 5ac96c612 "More mutex locking for SCH_FIELDs.": https://jenkins.simonrichter.eu/job/linux-kicad-head/2681/testReport/ Simon signature.asc Description: OpenPGP digital signature ___ Mailing

Re: [Kicad-developers] Bus upgrades merge

Tom, On 4/3/2019 1:34 PM, Tomasz Wlostowski wrote: > On 02/04/2019 17:27, Wayne Stambaugh wrote: >> We should always be using wxLogTrace. Using printf and cout are >> meaningless on windows and wxLogDebug means that your debugging output >> is always spewed on debug builds even when it's not

Re: [Kicad-developers] Bus upgrades merge

On 02/04/2019 17:27, Wayne Stambaugh wrote: > We should always be using wxLogTrace. Using printf and cout are > meaningless on windows and wxLogDebug means that your debugging output > is always spewed on debug builds even when it's not needed. I haven't > made the draconian move of making this

Re: [Kicad-developers] More wxString multi-threading issues

Hi Tom, I’m pretty sure it's any iterator, not just a non-const one. And they’re used internally for things such as Length() and IsEmpty(). I wonder if you could do the mutex locking inside KiString, though? Or would that kill performance? (You could avoid it on Length() and IsEmpty() by

Re: [Kicad-developers] More wxString multi-threading issues

Unfortunately it is quite complicated (probably significantly more complicated than fixing the string issues) to do an "incomplete" update of the netlist, since the netlist is globaly interdependent in order to make things like hierarchy and global labels work. I have some avenues to pursue here

Re: [Kicad-developers] More wxString multi-threading issues

On 03/04/2019 17:42, Wayne Stambaugh wrote: > I would be reluctant to get behind this just because of the possibility > of epic string breakage on lot's of levels. If there was some way to > piece meal this transition, it might be more palatable but that may > prove to be very difficult. > > The

Re: [Kicad-developers] More wxString multi-threading issues

I would be reluctant to get behind this just because of the possibility of epic string breakage on lot's of levels. If there was some way to piece meal this transition, it might be more palatable but that may prove to be very difficult. The need to use threads, is less clear. It may be far less

Re: [Kicad-developers] More wxString multi-threading issues

I think I misspoke when I mentioned UTF-16. The compile switch just changes the internal representation of wxStrings from UFT-8-encoded char’s to non-UTF-8-encoded w_char_t’s. This wouldn’t have endian issues, would it? > On 3 Apr 2019, at 16:15, Seth Hillbrand wrote: > > Hi Jeff- > > The

Re: [Kicad-developers] More wxString multi-threading issues

I’m currently trying a build with no wxString reference in that particular spot, and overriding the routine at the SCH_FIELD level to lock a mutex when copying the string to the stack. I’ll email again once I have results…. (Note however that this is a piecemeal approach: we’d still have to

Re: [Kicad-developers] More wxString multi-threading issues

Hi Jeff- The major downside to our using UTF-16 is that it is not endian-independent. Unless we drop support for big-endian platforms, we'll need to handle both cases. I needn't tell you what a pain that would be. Maybe we can just not return wxString references? Enforce a getter/setter

Re: [Kicad-developers] More wxString multi-threading issues

I think we will want to use threading in more places going forward in order to enable more powerful features without hurting GUI responsiveness. I am in favor of exploring any solutions that make it easier to use threads -- as Jeff mentioned, the problem I'm tackling now does not relate to

Re: [Kicad-developers] More wxString multi-threading issues

Hi Brian, The globals wouldn’t be so bad. It’s the EDA_TEXT’s m_Text field that’s the biggest issue. Protecting that would mean no longer returning a reference from GetText(). But that might not be so terrible…. FWIW, Kicad does use wchar_t everywhere it fetches or sets a wxString. It’s

Re: [Kicad-developers] More wxString multi-threading issues

My $0.02: Is shifting the whole of kicad to wchar_t (along with all the necessary conversions to/from multibyte for IO) easier than wrapping some globals inside locks for thread-safety? Having dealt with an application that uses ASCII, UTF-16, and UTF-8 in various contexts (my day job), I can

Re: [Kicad-developers] Bus upgrades merge

Tom and I were both doing penance for having added one of those arrays, so it was time to get us out of Purgatory. ;) > On 3 Apr 2019, at 13:37, Jon Evans wrote: > > Thanks Jeff! Changes look good to me. > > On Wed, Apr 3, 2019 at 6:28 AM Jeff Young > wrote: > Changes

[Kicad-developers] More wxString multi-threading issues

Jon is currently fighting another wxString multi-threading issue. Having done quite a few of these myself, I feel for him. A lot of them were threaded accesses to globals, so it was easy enough to make the globals std::strings. However, this one is EDA_TEXT’s m_Text field. That’s going to

Re: [Kicad-developers] Bus upgrades merge

Thanks Jeff! Changes look good to me. On Wed, Apr 3, 2019 at 6:28 AM Jeff Young wrote: > Changes are in. Jon (in particular) will want to pick them up soon. > > An array of SCH_PIN (mapped by LIB_PIN*) was created which replaces: > - the array of highlight flags > - the array of pin positions

Re: [Kicad-developers] Bus upgrades merge

Changes are in. Jon (in particular) will want to pick them up soon. An array of SCH_PIN (mapped by LIB_PIN*) was created which replaces: - the array of highlight flags - the array of pin positions - the array of brightened flags - the sparse array of dangling indices - the array (mapped by

Re: [Kicad-developers] [eeschema] Names/descriptions for units

Understood - is this the only issue with it? Like I said I'm very happy for the information to be stored elsewhere, and will adapt my patch as soon as unit descriptions are part of the format. Can you please email the list or myself when that happens and let me know? Kliment On 27.03.19 16:58,