kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/16/2014 5:48 AM, Derek Kozel wrote:
> :) I'll try and fix it today.

Thanks!

> 
> My question was more of a procedural one. Does the development team
> prefer that I use the 593782 bug as the reference for this fix, as the
> problems are in the same vicinity, or should I open a new bug given that
> the original problem is actually fixed and post my patch referring to
> the new bug report? I've worked at companies that work both ways and one
> that didn't even require a report for a patch.

Since the duplicate name issue still exists due to file name case
sensitivity on Window, I would say go ahead an use the current bug
report since it has not been tagged as fix committed.  Go ahead and add
the display refresh fix to it as well rather than file another bug report.

> 
> On 08/15/2014 10:04 PM, Dick Hollenbeck wrote:
>> On 08/15/2014 03:18 PM, Derek Kozel wrote:
>>> 'eeschema' allows instances with the same name 
>>> https://bugs.launchpad.net/kicad/+bug/593782
>>>
>>> I've just checked this bug and the faulty behaviour has already been fixed in the
>>> current revision. However there is still an incorrect behaviour where the symbol for
>>> the hierarchical sheet is still drawn on the sheet after the error dialog is displayed
>>> until the schematic is redrawn (refreshed?). Should this be opened as a new bug and the
>>> old one closed?
>> Better would be to actually fix it and send in a patch.   :)
>>
>> Lately I've been having a lot of luck with late model kdbg on linux.
>>
>> It has a nice "break" feature that lets you break into the source once you are in the
>> vicinity of the the bug.  It helps to load up the stack, and this is best done by being in
>> a dialog window before you "break".  Otherwise the stack is pretty lean since that App
>> will be dispatching events from the top level event loop.
>>
>> Once you break in under the debugger (while in a dialog window pertinent to the problem),
>> you should see full source code.  The stack trace is your friend.   You can point to any
>> caller in the stack trace, and kdbg will bring up the source code.  I even have mine setup
>> to pull up wx source code too.  So I can step through full wx source code.
>>
>> Then you can place a breakpoint on something you want to go to.  Then "run" again from
>> there to that break point, which is invariably in some kind of event handler.  The entire
>> program is an event handler right?
>>
>> Pull up that code, fix it in your editor, rebuild, run it again, and send in a patch.
>>
>> You'll need many out of tree build dirs, I have one called build-debug, and the object
>> files in there were built with full debugging information using CMAKE_BUILD_TYPE=Debug.
>>
>> I have another called build-release, this one I install and use day to day.  The Debug one
>> rarely gets installed, except when I want to run it not under a debugger but still have
>> the asserts.
>>
>>
>>
>>> As an additional note, the check for uniqueness is case insensitive. "Sheet" and
>>> "sheet" cannot exist on the same schematic.
>>>