Re: [Kicad-developers] [PATCH] Replace remaining Boost Mutexes with std::mutex

Am 2019-05-03 14:04, schrieb Ian McInerney: This patch series removes the last uses of MUTEX and MUTLOCK from the code base, so now everything is using std::mutex and std::lock_guard instead of the Boost provided classes. I have also removed the ki_mutex.h header file since this is no longer

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

I was just trying to find this discussion in the video, can you give the time? The link to the video is here, for the future generations of internet search engine users who find this thread: https://www.youtube.com/watch?v=NRwTyBX2BFk Eeli Kaikkonen

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

I have no doubt about the difficulty of plumbing something like this feature into KiCad. Most things are easier said than done. A few thoughts in response 1. My initial thought was to skip generating a graphical schematic, and to simply join in essence two or more netlists while avoiding name

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

Jon My thought was simply that: a quick way of switching between sheets. Lets say I am in the main sheet and want to look at a circuit 2 levels down: I have to find the right sheet, click it, find the next sheet, click that, have a look, then backup and backup. I have found it much

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

Hi Brian, There already is an easier way to navigate sheets than what you describe: click "Navigate schematic hierarchy" button on top toolbar or "View -> Show hierarchical navigator" which both open same view of schematic sheet tree. Single click on any sheet will bring you directly to it so in

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

One thing I liked from Eagle was the list of sheets as thumbnails to allow for visual recognition. Regards Russell Oliver On Sat, 4 May 2019 at 10:20, Andrew Lutsenko wrote: > > Hi Brian, > > There already is an easier way to navigate sheets than what you describe: > click "Navigate

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

I just said that we are not capable of providing atomic symbols because we have no idea what this means to each user but that doesn't mean that they will not be able to implement them on their own. There is no plan to change the current allowable work flows. Once the symbol and schematic

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

You wouldn't necessarily need to create a graphical representation for the import, just a representation that will work with the connectivity graph. Because the connectivity graph is currently tied to the graphical/physical layout of items (specifically, it looks at how item connection points

Re: [Kicad-developers] eemodern merge request

I pushed another set of commits to origin/eemodern. All of Seth’s issues should now be fixed. Cheers, Jeff. > On 3 May 2019, at 22:00, Jeff Young wrote: > > Good enough for me. > > Cheers, > Jeff. > >> On 3 May 2019, at 21:14, Wayne Stambaugh > > wrote: >> >>

[Kicad-developers] [Patch] Fixes for the github 3D library fetching dialog

The attached patch modifies the behavior of the wizard for fetching the 3d libraries from github to fetch the list of libraries if the URL is modified by the user (e.g. if they go to page 2, then back to page 1 and modify the URL it will now fetch the library list for the modified URL). It also

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

On 5/3/2019 4:59 PM, Rene Pöschl wrote: > On 03/05/19 22:48, Eeli Kaikkonen wrote: >> I was just trying to find this discussion in the video, can you give >> the time? >> >> The link to the video is here, for the future generations of internet >> search engine users who find this thread: >>

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

On 03/05/19 22:48, Eeli Kaikkonen wrote: I was just trying to find this discussion in the video, can you give the time? The link to the video is here, for the future generations of internet search engine users who find this thread: https://www.youtube.com/watch?v=NRwTyBX2BFk Around 4

Re: [Kicad-developers] eemodern merge request

Good enough for me. Cheers, Jeff. > On 3 May 2019, at 21:14, Wayne Stambaugh wrote: > > On 5/3/2019 4:08 PM, Jeff Young wrote: >> Hi Seth, >> >> Thanks for the feedback! >> >>> - Right-click inside a subsheet should have exit sub sheet as the first >>> option >> >> Really? This sort of

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

The person in the forum misunderstood your intention, he thought you opposed the idea of atomic libraries. I interpreted you meaning that the KiCad's own libraries won't be atomic. There's no need to engage, we will send your positive message there, namely that all workflows will always be fully

Re: [Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

On 03/05/19 23:14, Wayne Stambaugh wrote: On 5/3/2019 4:59 PM, Rene Pöschl wrote: On 03/05/19 22:48, Eeli Kaikkonen wrote: I was just trying to find this discussion in the video, can you give the time? The link to the video is here, for the future generations of internet search engine users

Re: [Kicad-developers] 6.0 string proposal

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. This design document makes for fascinating reading:

Re: [Kicad-developers] 6.0 string proposal

Dick, On 5/2/19 6: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

[Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

Hello Devs This is well beyond my capabilities, but I have been wondering if having tabbed schematics is a viable feature for eeSchema? Currently you have to open another instance of eeSchema or click through to sheets in order to see other sheets. Tabs would be more convenient than

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

I have uploaded a build of the eemodern branch on https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/lastSuccessfulBuild/artifact/out/pack-x86_64/kicad-patched-330-5.1.0-437-gc807783d7-x86_64.exe On Fri, 3 May 2019 at 14:06, Brian Piccioni wrote: > > Hello Devs > > > > This is well

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

On 5/2/19 9:34 PM, Jon Evans wrote: > Neat idea, Russell! > > In theory, this is possible.  In practice, there are many challenges to > overcome. > > The internal representation of the schematic does not resemble the > netlist that is given to PcbNew. > So, a PcbNew netlist (whether generated

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

Am 2019-05-03 08:05, schrieb Brian Piccioni: Hello Devs This is well beyond my capabilities, but I have been wondering if having tabbed schematics is a viable feature for eeSchema? Currently you have to open another instance of eeSchema or click through to sheets in order to see other sheets.

Re: [Kicad-developers] 6.0 string proposal

On 5/3/2019 10:49 AM, Jeff Young wrote: > @Wayne, are you sure about those settings?  (That’s the flag I proposed > we flip in the previous incantation of this thread.)  I’m fairly sure > (although not 100% certain) that the bug only exists in > wxUSE_UNICODE_UTF8 mode. If that is the case, could

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

The reason I haven't even considered a tabbed UI is that wxAui in wx3.0 is still not reliable enough. wxAui would allow us to have tabs that can be torn from the main window and placed on multiple monitors. We could just use "dumb" tabs now but in the long run, it will just be additional

Re: [Kicad-developers] 6.0 string proposal

This is the only bug I could find in the database: https://bugs.launchpad.net/kicad/+bug/1822678. Note that the Michaels (both Geselbracht and Kavanagh) are on OSX. There’s also the two I fixed (neither of which was logged as I couldn’t figure out how to reproduce them). Once again, OSX.

Re: [Kicad-developers] 6.0 string proposal

It seems like this is macos specific. Don't we have our own custom wxwidgets builds for macos? Maybe we should change the build flags. On 5/3/2019 12:34 PM, Jeff Young wrote: > This is the only bug I could find in the database: > https://bugs.launchpad.net/kicad/+bug/1822678. Note that the

Re: [Kicad-developers] 6.0 string proposal

Thanks Jeff. On 5/3/19 4: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. The fact that

Re: [Kicad-developers] 6.0 string proposal

Thanks Wayne for giving me a chance to participate. Jeff has been very helpful so far. Before we setup a small group communications mechanism, I look forward to Jeff's further input. I think the needs analysis is important before we build a solution work environment. Maybe there's a simple

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

On Fri, 3 May 2019 at 14:06, Brian Piccioni wrote: Currently you have to open another instance of eeSchema or click through to sheets in order to see other sheets. Tabs would be more convenient than clicking on a sheet (or multiple levels of sheets), backing out, etc., at least in many

Re: [Kicad-developers] 6.0 string proposal

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

Re: [Kicad-developers] 6.0 string proposal

Hi Jeff, I think it is the index access operator that performs this caching, to allow you to access the n'th code point any number of times while only iterating the string only once. However, you can still use the iterator access safely. It is only index based access that is cached and

Re: [Kicad-developers] eemodern merge request

While I wasn’t able to reproduce these, I have “fixes” in for them: 1) Tom’s dereference of freed memory 2) Seth’s place image crash (and disappearing image issue) These were reproducible, so I’m a bit more sure that they're are fixed: 3) Seth’s duplicate screen crash 4) Seth’s copy/paste

Re: [Kicad-developers] 6.0 string proposal

Could that damage have already been done by prior concurrent access? Maybe a subsequent read only operation fails because your linked list is already hay wired... Walking a linked list at a later point in time than when it was damaged can do this.. On 5/3/19 10:18 AM, Jeff Young wrote: > I

Re: [Kicad-developers] 6.0 string proposal

On 5/3/19 9:41 AM, Wayne Stambaugh wrote: > 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

Re: [Kicad-developers] 6.0 string proposal

When you implement command line switches you will probably want --help to emit a translated message. On Fri, May 3, 2019 at 1:51 PM Wayne Stambaugh wrote: > On 5/3/2019 11:27 AM, Dick Hollenbeck wrote: > > On 5/3/19 9:41 AM, Wayne Stambaugh wrote: > >> There is a secondary goal of removing

[Kicad-developers] In response to KiCon panel question "atomic" vs "CvPcb" answer

Hi, I hope i do not step out of line but i think there might be small misconceptions about the two major library workflows and i just wanted to give my insight of it. Generally speaking there are two time instances as to when a footprint is assigned to a symbol. One is at the end of the

Re: [Kicad-developers] eemodern merge request

Hi Seth, Thanks for the feedback! > - Right-click inside a subsheet should have exit sub sheet as the first option Really? This sort of presumes the most likely thing to do after entering a sheet is to leave it again. (It is in the menu, just further down.) > - Double-click on a subsheet

Re: [Kicad-developers] eemodern merge request

On 5/3/2019 4:08 PM, Jeff Young wrote: > Hi Seth, > > Thanks for the feedback! > >> - Right-click inside a subsheet should have exit sub sheet as the first >> option > > Really? This sort of presumes the most likely thing to do after entering a > sheet is to leave it again. (It is in the

Re: [Kicad-developers] eemodern merge request

Am 2019-05-03 11:09, schrieb Jeff Young: While I wasn’t able to reproduce these, I have “fixes” in for them: 1) Tom’s dereference of freed memory 2) Seth’s place image crash (and disappearing image issue) These were reproducible, so I’m a bit more sure that they're are fixed: 3) Seth’s

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

Thanks. I suspect that it doesn't require much change since one would be essentially changing the focus to a sheet in memory rather than reloading it. Brian -Original Message- From: Kicad-developers On Behalf Of Kevin Cozens Sent: May 3, 2019 10:36 AM To: kicad-developers Subject:

Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed schematics?

If this is essentially adding a faster way to switch between sheets, it should be very straightforward. If instead you want to be able to view more than one sheet at a time (side by side tabs, or something), it would be more complex because currently Eeschema has a lot of code that expects only a

Re: [Kicad-developers] 6.0 string proposal

John I got this too from reading the class documentation an hour ago. To smoke these out, a person could comment out the undesirable calls in a wx header, perhaps one that was temporarily moved into a place at a higher priority in the INCLUDE file search space. Then "make -i" perhaps on a

Re: [Kicad-developers] 6.0 string proposal

I did a bit more sleuthing. Turns out wxUSE_UNICODE_UTF8 is on for OSX. I misread it because wxUSE_STRING_POS_CACHE is Linux-only: #if wxUSE_UNICODE_UTF8 && !defined(__WINDOWS__) && !defined(__WXOSX__) #define wxUSE_STRING_POS_CACHE 1 #else #define wxUSE_STRING_POS_CACHE 0 #endif … and

Re: [Kicad-developers] 6.0 string proposal

Yes, we know exactly why it crashes: in order to speed up iterator access each iterator keeps a pointer into the last location accessed (so that i-1 and i+1 can be fast). These pointers are kept in a linked-list. Adding and removing pointers from this list is not thread-protected. Note that

Re: [Kicad-developers] 6.0 string proposal

More and more strange by the day. My OSX build also shows that wxUSE_UNICODE_UTF8 is off (and thereby wxUSE_STRING_POS_CACHE). Or at least CLion thinks it’s off (and highlights the code accordingly). I had earlier encouraged Jon to flip the switch to see what happened. I had meant locally,

Re: [Kicad-developers] 6.0 string proposal

I don’t believe that’s the case. Neither of the two crashes that I tracked down involved direct index access (or any change to the string). One was calling foo.IsEmpty(), and the other foo.Length(). Both use const iterators under the hood. When wxUSE_UNICODE_UTF8 is off, wxWidgets gets

Re: [Kicad-developers] 6.0 string proposal

I have not yet had a chance to flip any switches anywhere. I could never reproduce these string crashes locally on my Linux machine, I just relied on others' reports. On Fri, May 3, 2019 at 11:16 AM Jeff Young wrote: > More and more strange by the day. My OSX build also shows that >

[Kicad-developers] [PATCH] Replace remaining Boost Mutexes with std::mutex

This patch series removes the last uses of MUTEX and MUTLOCK from the code base, so now everything is using std::mutex and std::lock_guard instead of the Boost provided classes. I have also removed the ki_mutex.h header file since this is no longer needed (and found an extraneous inclusion in the

Re: [Kicad-developers] 6.0 string proposal

On 5/3/2019 11:27 AM, Dick Hollenbeck wrote: > On 5/3/19 9:41 AM, Wayne Stambaugh wrote: >> 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

Re: [Kicad-developers] 6.0 string proposal

It takes some lead to hit a moving target. You know this if you have ever shot clay pigeons. Do we have any evidence that computers are going to have more memory in the future? If so, then this class might be useful: http://www.cplusplus.com/reference/string/u32string/ I actually don't

Re: [Kicad-developers] Pcbnew display origin transforms for v6

Hi Wayne, No worries on formatting. As a senior professional software engineer I'm used to dealing with formal coding conventions and I'm keeping the web page open while I'm writing. I prefer the K style myself, but I'm not going to lose sleep over the differences. I had a bit of trouble

Re: [Kicad-developers] Pcbnew display origin transforms for v6

Reece, On 5/3/2019 2:09 PM, Reece R. Pollack wrote: > Hi Wayne, > > No worries on formatting. As a senior professional software engineer I'm > used to dealing with formal coding conventions and I'm keeping the web > page open while I'm writing. I prefer the K style myself, but I'm not > going to

Re: [Kicad-developers] 6.0 string proposal

Yes, we build wxwidgets ourselves! Let me know what settings I should set, and we can get test builds out shortly! https://github.com/KiCad/kicad-mac-builder/blob/master/kicad-mac-builder/wxpython.cmake Adam On Fri, May 3, 2019 at 11:52 AM Wayne Stambaugh wrote: > > It seems like this is