Fantastic! Thanks very much Wayne
On 22 Nov 2017 01:17, "Wayne Stambaugh" wrote:
> Yeah!! I finally got this merged. Thank you Oliver for your
> contribution to KiCad and for your patience.
>
> Cheers,
>
> Wayne
>
> On 11/21/2017 12:51 AM, Oliver Walters wrote:
> > Wayne,
> >
> > I have recrea
Yeah!! I finally got this merged. Thank you Oliver for your
contribution to KiCad and for your patience.
Cheers,
Wayne
On 11/21/2017 12:51 AM, Oliver Walters wrote:
> Wayne,
>
> I have recreated the patch set once again, and there is no reference to
> "printf" in any of these patch files.
>
Wayne,
I have recreated the patch set once again, and there is no reference to
"printf" in any of these patch files.
Please apply with the --ignore-whitepace flag, the file
/include/lib_table_grid.h is full of MS-DOS line endings and I believe this
is the cause.
Patch set attached, hopefully wor
Wayne,
Ok, apologies I thought I had addressed that (I haven't had a chance to go
back and look at these patches). I'll do so tonight.
On Tue, Nov 21, 2017 at 10:00 AM, Wayne Stambaugh
wrote:
> I looked at patches 3-6 and I didn't see where the printf was removed.
>
> On 11/20/2017 05:47 PM, Ol
I looked at patches 3-6 and I didn't see where the printf was removed.
On 11/20/2017 05:47 PM, Oliver Walters wrote:
> The printf() statement should be removed in one of the subsequent
> patches, as should the removal of that line. I'm unable to check this
> right now, are you able to confirm if o
The printf() statement should be removed in one of the subsequent patches,
as should the removal of that line. I'm unable to check this right now, are
you able to confirm if one of the later patches fixes this problem?
On Tue, Nov 21, 2017 at 9:44 AM, Wayne Stambaugh
wrote:
> I made a change to
I made a change to fix a bug with the default plugin type when appending
a new row to the table which caused the conflict. This where I noticed
the printf() debugging statement. I also noticed that it appears that
you removed a scroll to row call and I'm not sure how to reconcile the
conflict. D
Wayne,
I think it is a whitespace issue, does it apply if you add
--ignore-whitespace to git-am ?
On Tue, Nov 21, 2017 at 1:03 AM, Wayne Stambaugh
wrote:
> Oliver,
>
> No go yet again. It looks like my commit 8b2b1381 is causing a conflict
> with patch 2 so please rebase your patches. I also
Oliver,
No go yet again. It looks like my commit 8b2b1381 is causing a conflict
with patch 2 so please rebase your patches. I also noticed a printf()
debugging statement in patch 2. Please remove this and make sure there
are not any other printf() statements in your patches. Sorry about
asking
Wayne,
I'm at a loss too. git am fails on 0002 but git apply works fine on each
individual patch.
On Mon, Nov 20, 2017 at 3:29 AM, Wayne Stambaugh
wrote:
> Oliver,
>
> Still no luck. Did you possible do something to mess up the commit
> ordering? I am applying these patches on top a clean mas
Oliver,
Still no luck. Did you possible do something to mess up the commit
ordering? I am applying these patches on top a clean master branch so
I'm not sure what is going on here. I'm getting the following error
from `git am` when I attempt to merge patch 2:
Applying: Toggle LIB_TABLE_ROW ena
Wayne
Please find updated patch set attached. I have rebased and built from
commit b6884d and it all works fine.
Thanks
On Sun, Nov 19, 2017 at 4:42 AM, Wayne Stambaugh
wrote:
> Oliver,
>
> I just tried to apply your patches and ran into some issues. Patch 1
> applies but patch 2 fails. Woul
Oliver,
I just tried to apply your patches and ran into some issues. Patch 1
applies but patch 2 fails. Would you please rebase your patches so I
can get them merged as soon as possible.
Thanks,
Wayne
On 11/15/2017 06:41 AM, Oliver Walters wrote:
> Wayne, et al,
>
> I am really liking the wa
Thank you!
On 18 Nov 2017 00:47, "Wayne Stambaugh" wrote:
> Oliver,
>
> I took another look at your patch set and I see now that the library
> table files only change when there are disabled libraries. This will
> ensure that the footprint library tables will be compatible with
> previous versi
Oliver,
I took another look at your patch set and I see now that the library
table files only change when there are disabled libraries. This will
ensure that the footprint library tables will be compatible with
previous versions of KiCad as long as users don't disable any libraries.
I will merge
Wayne,
Please confirm if you really do not want this feature now. This thread is
quickly turning into a how-to for the new symbol table :)
Thanks
On Thu, Nov 16, 2017 at 8:42 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:
>
> On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh
> wrot
On 16/11/17 17:41, Kevin Cozens wrote:
On a side note, you might see a trailing / for the KISYS3DMOD environment
variable. That is there by default when you first run KiCad. I would remove
that extra character for consistency. So far I have not noticed any negative
effects when the path for KISYS
On 2017-11-16 05:00 AM, Fabrizio Tappero wrote:
I have deleted the lib table and let kicad propose the new one so now all is
fine.Â
The only problem I experienced is that the "RESCUE" rename action has
screwed up all my schematics. Thank god git was made.
Make sure you do *not* have a / char
Hey Wayne,
thanks for the link. I have read it and followed the steps. All is working
now.
Thanks a lot for the info.
cheers
Fabrizio
On Thu, Nov 16, 2017 at 1:38 PM, Wayne Stambaugh
wrote:
> Did you follow the instructions I provided on the kicad website blog post?
>
> http://kicad-pcb.org/p
Did you follow the instructions I provided on the kicad website blog post?
http://kicad-pcb.org/post/symbol-lib-table/
On 11/16/2017 5:20 AM, Fabrizio Tappero wrote:
> hi Guys,
> I can confirm that the recent lib table commits have made my working
> version of kicad totally unable to open recent
Hi Guys,
hum... my version of kicad is a nightly buid that I heavily use at work and
that keep update every now and then. Probably all this started a two years
ago or so.
I have deleted the lib table and let kicad propose the new one so now all
is fine.
The only problem I experienced is that the
On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh
wrote:
> Gentlemen,
>
> I'm not sure about breaking the library table file format for the
> version 5 release. If we do, the footprint library table will not be
> compatible with older versions. I would prefer that we push this change
> into vers
Where did you get your symbol library table file from?
${KICAD_SYS_SYMBOL_DIR} is not correct. It should be
${KICAD_SYMBOL_DIR}. This is the environment variable used in the
default library table at
https://github.com/KiCad/kicad-library/blob/master/template/sym-lib-table
On 11/15/2017 12:05 PM
please see KICAD_SYS_SYMBOL_DIR != KICAD_SYMBOL_DIR
> On 16/11/2017, at 06:05, Fabrizio Tappero wrote:
>
> Hi,
> I am not sure what the problem is but after a recent nightly build update I
> have lost all my schematic libs. This is the lib table config
>
>
>
> all lib files are in /usr/sh
Gentlemen,
I'm not sure about breaking the library table file format for the
version 5 release. If we do, the footprint library table will not be
compatible with older versions. I would prefer that we push this change
into version 6.
I'm OK with the progress dialog. If you split that out as se
On 15/11/17 15:30, Maciej Suminski wrote:
> Hi Oliver,
>
> Thank you for restoring the progress bar dialog. While the library load
> time has recently decreased a lot, the UI freeze still happens with long
> library lists.
> Disclaimer: I have not looked at the code yet, I am just praising the ide
Hi Oliver,
Thank you for restoring the progress bar dialog. While the library load
time has recently decreased a lot, the UI freeze still happens with long
library lists.
Disclaimer: I have not looked at the code yet, I am just praising the idea.
As you are looking on the Symbol Library Table
27 matches
Mail list logo
