Re: [Kicad-developers] Warning about potentially malicious software

[Dick Hollenbeck]

On 10/21/21 8:14 AM, Wayne Stambaugh wrote:
> On 10/21/21 9:03 AM, Dick Hollenbeck wrote:
>> On 10/19/21 3:29 PM, Seth Hillbrand wrote:
>>> we attempted to secure the rights to the original domain name from Dick 
>>> without success.
>>
>> This is untrue.  *No* offer was ever made, neither to re-imburse nor any 
>> offer to purchase was ever made.
>>
>> "we attempted" is actually rediculous.   "we" is funny.  "attempted" is 
>> funny,
>>
>> When Wayne lets this mis-characterization happen without stepping up to 
>> clarify, that is far less than what I would
>> expect from an old friend.
> 
> Dick is correct.  I dropped the ball on this after our last email as it 
> just fell off of my radar with everything that is going on.  Mea culpa.
> 
> Wayne

Thank you.

___
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] Warning about potentially malicious software

[Dick Hollenbeck]

On 10/19/21 3:29 PM, Seth Hillbrand wrote:
> we attempted to secure the rights to the original domain name from Dick 
> without success.

This is untrue.  *No* offer was ever made, neither to re-imburse nor any offer 
to purchase was ever made.

"we attempted" is actually rediculous.   "we" is funny.  "attempted" is funny,

When Wayne lets this mis-characterization happen without stepping up to 
clarify, that is far less than what I would
expect from an old friend.


___
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] Internet domain names

[Dick Hollenbeck]

The domain name

kicad-pcb.org has been recently sold.

The domain name

kicad-pcb.com is currently for sale.

Contact d...@softplc.com if interested please.


___
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] A useful CMake trick

[Dick Hollenbeck]

Guys,

Here is a technique that might be helpful someday.  I found this article (blog 
post) helpful, because it advances a
CMake external project build step into the configure phase up out of the 
baseline project build phase.  It is summarized
by the last paragraph in the blog post:




Generalising for any external project

There’s no inherent assumption in the above which restricts this approach to 
just gtest or gmock. It can be generalised
to support any external project which uses CMake as its build system. This 
essentially amounts to parameterising the
project name and the download, source and binary directories inside a CMake 
function. It can also be made to support
more than just git clone/checkout as a download method, it can easily support 
anything ExternalProject itself supports.
I’ve already gone ahead and done all the work for you, so just grab it from the 
Github project associated with this
article. It even includes a simple example with gtest and gmock test cases to 
show how to use it. Enjoy!





https://crascit.com/2015/07/25/cmake-gtest/

HTH,

Dick

___
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] KiCad GitHub plugin opinions

[Dick Hollenbeck]

Hi Seth,

We still use the plugin here internally, but not with github.  It is 
configurable to
simply use zip files as libraries, from any zip file URL.

When that zip file URL is on a local server, and especially on a fast disk such 
as a new
PCIe ssd this becomes the fastest plugin by far.  We actually run out of a ram 
disk on our
internal server.
The plugin can also tolerate footprint changes because it inherits from PCB_IO, 
giving it
an overlay union of the two data sources.  But we use those local files as a 
work queue
for scrutiny and shared distribution.

The speed when used locally like this is far faster than any other plugin.

You might simply just rename the plugin to the zip file plugin, it might fit 
better with
the most common recommended use case.  Even when we were using it with github, 
we always
used nginx to cache the zip files locally in a proxy server.

Evidently it is faster to load one big zip file than the hundreds of small 
files used by
the PCB_IO plugin.

Given that is can be disabled during compilation, I would prefer that it not be 
removed. 
I would not object to making the default be OFF.  And lastly I think it serves 
as another
plugin that is likely to be a useful reference for future plugin writers.


Summary of my preferences:  would prefer it be kept, we are using it 
internally.  Rename
it to "zip file" plugin, default it to OFF.


Thanks,


Dick





On 10/28/20 10:25 AM, Seth Hillbrand wrote:
> Hi Folks-
>
> We are currently discussing the removal of the GitHub plugin from KiCad 
> library
> management. Didn’t know that KiCad had a GitHub plugin? Then this will not 
> affect you at
> all.
>
> We’re looking for users that actively use the GitHub plugin for their 
> professional work
> and would be affected by its removal.
>
> If this is you, please reply here with how you are using the plugin and we’ll 
> see what
> we can do to support your use case going forward.
>
> Thanks-
> Seth
>
> -- 
> KiCad Services Corporation Logo
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com     i...@kipro-pcb.com
> 
>
>
> ___
> 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] What is this build error?

[Dick Hollenbeck]

On 9/4/20 8:38 AM, Dick Hollenbeck wrote:
> Any idea, in Fossa terms, what this missing library
> set is named?

found it:

libgtk-3-dev



___
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] What is this build error?

[Dick Hollenbeck]

$ make
-- KICAD_SCRIPTING is OFF: Disabling all python scripting support
-- KiCad install dir: 
-- Enabling warning -Wsuggest-override
-- Enabling warning -Wduplicated-branches
-- Enabling warning -Wduplicated-cond
-- Enabling error for -Wvla
-- Enabling warning -Wimplicit-fallthrough
-- Enabling error for -Wreturn-type
-- Enabling warning -Wshadow
-- Enabling warning -Wsign-compare
-- Enabling warning -Wmissing-field-initializers
-- Enabling warning -Wempty-body
-- Enabling warning -Wreorder
-- Check for installed GLEW -- found
-- Check for installed ZLIB -- found
-- Creating linux metadata
-- Using Git to determine build version string.
-- Checking for module 'gtk+-3.0'
--   No package 'gtk+-3.0' found
CMake Error at /usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:463 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:643 
(_pkg_check_modules_internal)
  libs/kiplatform/CMakeLists.txt:29 (pkg_check_modules)


-- Configuring incomplete, errors occurred!
See also "/ssd/build/kicad-pristine/CMakeFiles/CMakeOutput.log".
See also "/ssd/build/kicad-pristine/CMakeFiles/CMakeError.log".
make: *** [Makefile:1702: cmake_check_build_system] Error 1


I am on Ubuntu Focal Fossa.


CMake could not find it, and I could not find it.

There is no package name gtk+-3.0.  Any idea, in Fossa terms, what this missing 
library
set is named?  Or is there a compatibility issue on Fossa with the library 
search?

Also, are we happy with the detail in this error message?  I find it less than 
helpful,
because it did not help me solve the problem.

Thanks,

Dick



___
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] What is a global variable, and why we don't need them.

[Dick Hollenbeck]

On 4/13/20 7:39 AM, Dick Hollenbeck wrote:
> Individual
> PROJECT clients view their libraries through the lens of their own 
> FP_LIB_TABLE.
> 
> If at that point shared pointers were introduced, it might be too bad to get 
> to shared
> libraries.  If something is in the way of this, then maybe you remove it.

Of course I meant in the FP_LIB_TABLE goes the shared pointers, and you'd have 
to track
which have been opened already in a name map.

Also, to help the guy who deletes a library part in Eeschema from one project 
that is not
using it, and just so happens to have another schematic open that is still 
using it, you
might give that guy some more shared pointers too.  This is when pointing to 
the library
part instead of including it.  Pcbnew is perhaps an easier implementation in 
this regard,
since it uses inclusion (=duplication) rather than pointer to footprints in a 
library.

In any case, other issues may be invisible from where we stand now.

But where there is a will, there is a way.






___
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] What is a global variable, and why we don't need them.

[Dick Hollenbeck]

On 4/12/20 8:50 AM, Brian wrote:
> Just out of curiosity, what’s an example use case for multiple projects open 
> at once, that
> isn’t served by multiple instances of KiCAD?  I admit I haven’t run into many 
> reasons to
> have more than one open at a time in my own usage other than occasionally 
> referring to an
> old project as a reference for a new one.
> 
> Cheers,
> -Brian
> 
> 
> 
>> Multiple projects open at once would be /really/ nice, though….
>>
>> Cheers,
>> Jeff.

When you open more than one copy of KiCad, you open more than one copy of the 
libraries.
This is like having the same document open in more than one text editor.  The 
last guy
wins, meaning there can be competition between the two editors for the state of 
the data
files, depending on who writes or saves last.

In the multiple projects under one process model, you would have to identify 
libraries
that are common among the two projects, and share them.  This overlap is a 
subset, not a
full duplication because of the "project specific" libraries can be different.  
Individual
PROJECT clients view their libraries through the lens of their own FP_LIB_TABLE.

If at that point shared pointers were introduced, it might be too bad to get to 
shared
libraries.  If something is in the way of this, then maybe you remove it.

Features like this, along with all the file conversions from foreign tools are 
great
attractors to the KiCad solution.  KiCad is uniquely positioned to continue to 
attract
users.  Being written in a relatively high level language means it has a 
powerful gas
pedal, and having a design that people can get their minds around, with clearly 
readable
code, all serve to encourage people into thinking that this is the way to go.  
Also, being
able to see that the design anticipates features not already implemented is no 
small thing.

Dick


___
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] What is a global variable, and why we don't need them.

[Dick Hollenbeck]

My definition:

I like to abstract the definition a little more than some designers, and 
include things
like singletons because a singleton intends to limit the number of instances to 
one.  I
would think you still have a global variable if you wrapped it into a class 
with a single
static instance.  You still only have one global instance.  That to me is still 
a global
variable with a fancy accessor, and that might even be worse.

If you can instantiate multiple instances, and the pointers to those instances 
are in
client user objects or on the stack, then you are probably not using a global.

Think of the world as being the *one* globe that we live on.  We have a global 
air supply,
and it spans all countries.  It is global because we cannot instantiate another 
instance
of the world's air supply, not because of how we spell its name, or where it 
exits.


The purpose of the PROJECT class was to create a place to store project 
specific objects,
with full intention of supporting more than one open project at some point in 
time.  You
can see this vision laid out in kiway.h.  Not a KiCad day goes by when I don't 
have
multiple KiCad projects open at the same time.  Currently, I typically am 
working on one
project under the project manager, but then load eeschema or pcbnew in 
singletop mode to
"view only" the other project data.

And even if multiple projects is not currently on the todo list, I think it is 
a mistake
to put road blocks in the path of supporting multiple projects at the same 
time.  It is
trivial to avoid those road blocks in most cases: avoid globals, including 
singletons
where one instance would not satisfy all projects. Instead, just use PROJECT 
and stuff
your PROJECT specific stuff into a PROJECT::_ELEM.

I recently got rid of g_RootSheet by using PROJECT.  It evolved through a can 
of worms,
but the worms are now all dead.  And the result is better than the formerly 
closed can of
worms.

One of the coolest features of PROJECT is the "data on demand" paradigm, or 
some might
call it lazy loading.  For python clients and what not, and any type of window 
client of
the PROJECT, it leaves the loading code out of sight and in a common place.

The main danger is the use of the virtual destructors in PROJECT::_ELEM.  That 
takes some
getting used to.  You must destroy any PROJECT elements that you own before 
your DSO gets
kicked out of process. This means as you exit EESCHEMA, that DSO might get 
unloaded from
ram, particularly if all windows in eeschema are closed.  I don't know that 
this unloading
happens, but because it could happen, it is best to design for it.  And mostly 
that means
calling
  SetElem( ELEMTYPE, nullptr );

in your clients' last destructor.





___
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] [Feature Idea] A disable toggle on hierarchical sheets

[Dick Hollenbeck]

In a great number of cases we all use the "Do Not Stuff" flag to differentiate 
builds,
using the same PCB.  Works well in many cases.

But the conditional include for schematic hierarchical sheets is intended for 
the use case
where things must be mutually exclusive due to size contraints.  It simply 
won't all fit
onto the same PCB stuffed multiple ways, say because you have mutually exclusive
requirements for boards that are largely similar but differ in ways that make a 
DNS not
the answer.  Currently I'm looking at two different form factors, physical 
shapes of the
two boards.  The smaller board cannot even receive all the footprints.  And 
there is
enough complexity that simply duplicating the schematics into two different 
projects would
double the maintenance and increase the original development.





___
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] [Feature Idea] A disable toggle on hierarchical sheets

[Dick Hollenbeck]

On 3/21/20 10:33 AM, Seth Hillbrand wrote:
> On 2020-03-20 08:01, Dick Hollenbeck wrote:
>> Folks,
>>
>> I am trying to use the same hierarchical schematic and product two
>> board files.  So my
>> plan is to have a symlink for the board file which can point to either
>> of the two boards,
>> depending on which I am currently working on.
> 
> Hi Dick-
> 
> I'm hoping that we can explicitly deprecate sharing files between 
> projects in favor of an in-KiCad solution for reusing design blocks.  
> Having this functionality external to KiCad, as is the case with shared 
> files, can cause lots of problems (cached references, changes in one 
> project, etc) and requires the user to explicitly configure their 
> filesystem to support this.
> 
> Best-
> Seth


Seth,

All the conversations regarding the new schematic file format, going back many 
years ago,
long before you joined the project, have always spoke of reusable schematic 
hierarchical
subsheets.  I always used the term, "verilog like" to describe them.   And I 
was always
adamant that the parameter passing should be done at the call site, not within 
the shared
logic (as is the case now).

Earmarking this feature with a new fancy name like "design blocks" is just 
another name
for an old idea.  Verilog calls them modules.

But I promise you, never in any of those prior KiCad discussions, and AFAICT 
nor in the so
called duplicate issue that you pointed to, was there ever any mention of 
"conditional
inclusion/exclusion".  Conditional inclusion and conditional exclusion of 
design blocks is
what my idea brings to the table.  Sorry if it was not sexy, and did not use 
the new sexy
name for the old idea, or spoke too much of gaps I was willing to fill in in 
order to get
a working tool.

Hierarchical sheets are not only a redundant concept with design blocks, they 
are
literally an inadequate implementation of the same.
You would not keep both, but during the transition, people should be able to 
use either
term in conversations.

When reading my write up, a person should start with the title. Let that sink 
in.  Then
when reading the body of the write up, look for the feature that corresponds to 
the title.

If you want to ADD conditional inclusion and exclusion to a design block 
architecture
document, then we could probably meld these two concepts together.  Until then, 
I maintain
that this is a new idea.

The whole feature that I speak of is only a couple hundred lines of code or 
less.

Dick


A man once went to a magic show.  He decided he was not going to be tricked, so 
he spent
the whole time watching the magician's socks.  When he exited the theater he 
commented
that the show was very boring.
If you want to pay attention to the boring stuff, you are likely to miss the 
magic.



___
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] [Feature Idea] A disable toggle on hierarchical sheets

[Dick Hollenbeck]

On 3/21/20 10:33 AM, Seth Hillbrand wrote:
> On 2020-03-20 08:01, Dick Hollenbeck wrote:
>> Folks,
>>
>> I am trying to use the same hierarchical schematic and product two
>> board files.  So my
>> plan is to have a symlink for the board file which can point to either
>> of the two boards,
>> depending on which I am currently working on.
> 
> Hi Dick-
> 
> I'm hoping that we can explicitly deprecate sharing files between 
> projects in favor of an in-KiCad solution for reusing design blocks.  
> Having this functionality external to KiCad, as is the case with shared 
> files, can cause lots of problems (cached references, changes in one 
> project, etc) and requires the user to explicitly configure their 
> filesystem to support this.
> 
> Best-
> Seth

The write up I provided spoke of only one project, producing multiple boards.  
So you are
not following my write up as I intended it, and then to mark it a duplicate 
without even
understanding it is not helpful.

Remember now that it is possible to save the schematic netlist file to 
.net.
 Remember that it is possible to pcbnew standalone using any board name, and 
then a person
may load a netlist file of any name into that board file.

In fact, the netlist file could come from any non KiCad source, as long as its 
in one of
the compatible formats.

So your initial comments were so far off base, that frankly I was gobsmacked, 
completely
at a loss for words.  Perhaps you either did not spend enough time reading what 
I wrote,
or perhaps my writing was far poorer than I thought. I was extremely 
frustrated, because
frankly, this in my opinion was the best idea I've had for KiCad in 10 years.  
And I've
had a lot of good ideas WRT to KiCad, thousands of them.

As to your sentence:

"I'm hoping that we can explicitly deprecate sharing files between
projects in favor of an in-KiCad solution for reusing design blocks."


This is an incomprehensible sentence for me, only because I would react that 
way to any
sentence with sufficient ambiguity in it.


___
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] [Feature Idea] A disable toggle on hierarchical sheets

[Dick Hollenbeck]

In better English:

https://gitlab.com/kicad/services/kicad-doc/-/issues/779


___
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] [Feature Idea] A disable toggle on hierarchical sheets

[Dick Hollenbeck]

Folks,

I am trying to use the same hierarchical schematic and product two board files. 
 So my
plan is to have a symlink for the board file which can point to either of the 
two boards,
depending on which I am currently working on.

That's all fine in theory (but I'm not there yet).

There are some differences between the schematics of the two boards,  
peripherals only.  I
have put those into separate hierarchical sheets.  For example, one board might 
have 2
RS485 ports whereas the second one has 1 such port.

What would be really nice is if the hieracrhical sheet reference, the net 
binding site
under the new architecture, could be told that the referenced subsheet is 
disabled.  This
is simply a boolean toggle, but visible in graphical form.

When disabled, it would:

a) cause the netlist to be generated without the subsheet.
b) treat the net paths into the subsheet as "no connects" and not complain 
during ERC.

With this architecture, you could actually have multiple alternatives wired in 
place, and
then manually enable only one of the hierarchical sheet alternatives.  This 
would give you
the option of using a different alternative peripheral, but also give you the 
option of
employing pulldowns or similar instead of true no-connects.

I was thinking now is a good time to bring this up, because as sheet net 
bindings get
moved into the referencing site, and out of the referenced site (sheet), you 
now have a
referencing site specific place to store this flag.


Dick

___
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] kicad github wiki

[Dick Hollenbeck]

On 1/23/20 9:15 AM, Wayne Stambaugh wrote:
> The only other page is "Modular KiCad with Alternate Top Level
> Launchers". I'm not sure, but you might want to migrate this document
> to gitlab.

Two of the 3 launchers have been implemented.

The one not implemented is a python project manager.  What my vision for that 
was
primarily was two fold:

1) Easier extension of UI features for non C++ developers.

2) Finally capitilizing on the "class PROJECT" data aggregation so that 
multiple projects
could be open at the same time.

3) Create competition within the project, at the project manager level.  This 
was on the
theory that competition breeds success.  We see it in Linux Desktops, and 
elsewhere.
Mutual exclusion is not a requirement.


(I have never taken to the "C++ invokes python" construct.  I think a "python 
invokes C++"
construct is more elegant and simpler.)


When I started working on phase III of the modular KiCad design, I got 
road-blocked by the
radical departure of wxPython from SWIG.

But as I recall, the trick to getting it started again is to develop a python 
callable
interface to KIWAY.  Because this lets you open the wxFrames in C++ after 
execution
arrives in C++ at the KIWAY layer.

That is, speaking approximately, the trick to getting this to work is to create 
the python
mapping to the C++ class KIWAY.  Make

  /common/swig/kiway.i

or SIP equivalent functional.

Then you can simply load a PCBNEW or EESCHEMA wxFrame similar to how SingleTop 
does.

Holding multiple concurrent projects would be nice, but you will have to deal 
with
multiple open copies of any library opened by more than one project.  This 
probably means
referencing the libraries from more than one place rather than including all 
open
libraries in the PROJECT instance.  Shared pointer or something like that.


I know there are some python enthusiasts and gurus out there, take this ball 
and roll with
it if you want.  Maybe it snowballs.



Regards,

Dick



___
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] auto conversion of sch file not working

[Dick Hollenbeck]

The other confusing aspect of this is that my old schematic did list the 
dependent
libraries.  So why the *.pro file was key to which libraries were being used is 
perhaps a
legacy curiosity.

EESchema Schematic File Version 2
LIBS:mylib
LIBS:ttl_ieee
LIBS:power
LIBS:device
LIBS:conn
LIBS:linear
LIBS:regul
LIBS:74xx
LIBS:cmos4000
LIBS:adc-dac
LIBS:memory
LIBS:xilinx
LIBS:special
LIBS:microcontrollers
LIBS:microchip
LIBS:analog_switches
LIBS:motorola
LIBS:intel
LIBS:audio
LIBS:interface
LIBS:digital-audio
LIBS:philips
LIBS:display
LIBS:cypress
LIBS:siliconi
LIBS:contrib
LIBS:localports-cache



___
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] auto conversion of sch file not working

[Dick Hollenbeck]

On 1/21/20 9:59 AM, Wayne Stambaugh wrote:
> There should be an entry
> 
> [eeschema/libraries]
> LibNameN=mylib


Wayne,

You da man,
still.

Rene,

Thanks for extending a helping hand.

---

I loaded the schematic OK now.
I note that an improvement is possible.  After clicking "Remap Symbols", my 
*.pro file is
stripped of old library information

 *and is saved to disk*


before I subsequently am given a choice to "Save" or "Close" in the next part 
of the Remap
Symbols dialog activity sequence.

I would prefer that the modification of the *.pro file (on disk) only happen if 
I "Save".
 Because during multiple failed attempts, one has to revert to the original 
old-school
library laden *.pro file to try again.

This process is a bridge, it gets crossed, after which you don't need it again 
until
another project.  Sometimes these bridges can be put into special one-shot 
operated
*external* tools where they stay safe from code churn aka evolution.

In this case, it was my bad, the older *.pro got edited probably by a text 
editor
somewhere along the way.  Or I tried to use the newer one *.pro file with the 
old *.sch.

Bridge crossed.

My thanks to the team again.

Dick

___
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] auto conversion of sch file not working

[Dick Hollenbeck]

On 1/20/20 11:44 AM, Wayne Stambaugh wrote:
> Is mylib an entry in the list of libraries below the
> 
> LibDir=/i/pcbs/kicad_parts;/usr/local/share/kicad/library

Does this not illustrate a yes to your question?

>>> /i/pcbs/kicad_parts$ ll mylib*
>>> -rw-rw 1 dick develop 286715 Apr 16  2018 mylib.bak
>>> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.bck
>>> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.dcm
>>> -rw-rw 1 dick develop 300397 Sep 27 16:12 mylib.lib



> 
> entry in the project file?  After remapping, is there a mylib library
> entry in the project symbol library table with the correct path?

NO, because there is no sym-lib-table file being created in the project 
directory.  I
start the process with just the *.sch and the *.pro file in the directory, 
nothing else.
 Then start eeschema from the command line with the schematic on the command 
line.

The result of the load looks like the attached.


> 
> The remapping function uses the symbol library list from the project
> file to populate the project symbol library table to correctly remap the
> symbols.  As long as all of the original symbol libraries are loaded by
> the old library code, the remapping works unless the original symbol
> names are missing from the library.  In this case, the rescue feature
> should have caught that problem and created a rescue library from the
> symbol library cache before remapping.
> 
> On 1/20/20 11:25 AM, Dick Hollenbeck wrote:
>> Same is true if I try and load from project manager.
>>
>> On 1/20/20 10:24 AM, Dick Hollenbeck wrote:
>>> I want to use standalone EESCHEMA (standalone =: run from command line not 
>>> project
>>> manager) to load an old schematic.
>>>
>>> In the project *.pro file corresponding to the old schematic I see this 
>>> line:
>>>
>>> LibDir=/i/pcbs/kicad_parts;/usr/local/share/kicad/library
>>>
>>> In /i/pcbs/kicad_parts is a library that I made called mylib:
>>>
>>> /i/pcbs/kicad_parts$ ll mylib*
>>> -rw-rw 1 dick develop 286715 Apr 16  2018 mylib.bak
>>> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.bck
>>> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.dcm
>>> -rw-rw 1 dick develop 300397 Sep 27 16:12 mylib.lib
>>>
>>>
>>> $ eeschema old-board.sch
>>>
>>> leads to a well-known dialog :
>>>
>>>Remap Symbols
>>>
>>> Whether I choose to remap or not, I don't see the *ANY* properly rendered 
>>> parts in the
>>> subsequently drawn schematic.  Regardless of which library they may be in.
>>>
>>> (I thought the *.pro file's LibDir was supposed to establish a "search 
>>> path" for the old
>>> libraries?)
>>>
>>>
>>> At this point, I don't now how to load an old schematic using this version:
>>>
>>>
>>> Application: Eeschema
>>> Version: (5.99.0-635-ga5c7d452c), debug build
>>> Libraries:
>>> wxWidgets 3.0.4
>>> libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
>>> (+libidn2/2.0.4)
>>> nghttp2/1.30.0 librtmp/2.3
>>> Platform: Linux 4.15.0-74-generic x86_64, 64 bit, Little endian, wxGTK
>>> Build Info:
>>> Build date: Jan  4 2020 19:45:12
>>> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
>>> Boost: 1.65.1
>>> Curl: 7.58.0
>>> Compiler: GCC 7.4.0 with C++ ABI 1011
>>>
>>> Build settings:
>>> KICAD_SCRIPTING=OFF
>>> KICAD_SCRIPTING_MODULES=OFF
>>> KICAD_SCRIPTING_PYTHON3=OFF
>>> KICAD_SCRIPTING_WXPYTHON=OFF
>>> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
>>> KICAD_SCRIPTING_ACTION_MENU=OFF
>>> BUILD_GITHUB_PLUGIN=ON
>>> KICAD_USE_OCE=OFF
>>> KICAD_USE_OCC=OFF
>>> KICAD_SPICE=OFF
>>> KICAD_STDLIB_DEBUG=OFF
>>> KICAD_STDLIB_LIGHT_DEBUG=OFF
>>> KICAD_SANITIZE=OFF
>>>
>>
>>
>> ___
>> 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] auto conversion of sch file not working

[Dick Hollenbeck]

Same is true if I try and load from project manager.

On 1/20/20 10:24 AM, Dick Hollenbeck wrote:
> I want to use standalone EESCHEMA (standalone =: run from command line not 
> project
> manager) to load an old schematic.
> 
> In the project *.pro file corresponding to the old schematic I see this line:
> 
> LibDir=/i/pcbs/kicad_parts;/usr/local/share/kicad/library
> 
> In /i/pcbs/kicad_parts is a library that I made called mylib:
> 
> /i/pcbs/kicad_parts$ ll mylib*
> -rw-rw 1 dick develop 286715 Apr 16  2018 mylib.bak
> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.bck
> -rw-rw 1 dick develop785 Sep 27 16:12 mylib.dcm
> -rw-rw 1 dick develop 300397 Sep 27 16:12 mylib.lib
> 
> 
> $ eeschema old-board.sch
> 
> leads to a well-known dialog :
> 
>Remap Symbols
> 
> Whether I choose to remap or not, I don't see the *ANY* properly rendered 
> parts in the
> subsequently drawn schematic.  Regardless of which library they may be in.
> 
> (I thought the *.pro file's LibDir was supposed to establish a "search path" 
> for the old
> libraries?)
> 
> 
> At this point, I don't now how to load an old schematic using this version:
> 
> 
> Application: Eeschema
> Version: (5.99.0-635-ga5c7d452c), debug build
> Libraries:
> wxWidgets 3.0.4
> libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
> (+libidn2/2.0.4)
> nghttp2/1.30.0 librtmp/2.3
> Platform: Linux 4.15.0-74-generic x86_64, 64 bit, Little endian, wxGTK
> Build Info:
> Build date: Jan  4 2020 19:45:12
> wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
> Boost: 1.65.1
> Curl: 7.58.0
> Compiler: GCC 7.4.0 with C++ ABI 1011
> 
> Build settings:
> KICAD_SCRIPTING=OFF
> KICAD_SCRIPTING_MODULES=OFF
> KICAD_SCRIPTING_PYTHON3=OFF
> KICAD_SCRIPTING_WXPYTHON=OFF
> KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
> KICAD_SCRIPTING_ACTION_MENU=OFF
> BUILD_GITHUB_PLUGIN=ON
> KICAD_USE_OCE=OFF
> KICAD_USE_OCC=OFF
> KICAD_SPICE=OFF
> KICAD_STDLIB_DEBUG=OFF
> KICAD_STDLIB_LIGHT_DEBUG=OFF
> KICAD_SANITIZE=OFF
> 


___
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] auto conversion of sch file not working

[Dick Hollenbeck]

I want to use standalone EESCHEMA (standalone =: run from command line not 
project
manager) to load an old schematic.

In the project *.pro file corresponding to the old schematic I see this line:

LibDir=/i/pcbs/kicad_parts;/usr/local/share/kicad/library

In /i/pcbs/kicad_parts is a library that I made called mylib:

/i/pcbs/kicad_parts$ ll mylib*
-rw-rw 1 dick develop 286715 Apr 16  2018 mylib.bak
-rw-rw 1 dick develop785 Sep 27 16:12 mylib.bck
-rw-rw 1 dick develop785 Sep 27 16:12 mylib.dcm
-rw-rw 1 dick develop 300397 Sep 27 16:12 mylib.lib


$ eeschema old-board.sch

leads to a well-known dialog :

   Remap Symbols

Whether I choose to remap or not, I don't see the *ANY* properly rendered parts 
in the
subsequently drawn schematic.  Regardless of which library they may be in.

(I thought the *.pro file's LibDir was supposed to establish a "search path" 
for the old
libraries?)


At this point, I don't now how to load an old schematic using this version:


Application: Eeschema
Version: (5.99.0-635-ga5c7d452c), debug build
Libraries:
wxWidgets 3.0.4
libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 
(+libidn2/2.0.4)
nghttp2/1.30.0 librtmp/2.3
Platform: Linux 4.15.0-74-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
Build date: Jan  4 2020 19:45:12
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
Curl: 7.58.0
Compiler: GCC 7.4.0 with C++ ABI 1011

Build settings:
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_PYTHON3=OFF
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
KICAD_SCRIPTING_ACTION_MENU=OFF
BUILD_GITHUB_PLUGIN=ON
KICAD_USE_OCE=OFF
KICAD_USE_OCC=OFF
KICAD_SPICE=OFF
KICAD_STDLIB_DEBUG=OFF
KICAD_STDLIB_LIGHT_DEBUG=OFF
KICAD_SANITIZE=OFF

___
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] How to show pad in pcbnew by clicking pin in eeschema

[Dick Hollenbeck]

Quick help,

When I click on a pin in eeschema I get the disambiguating menu and then I say 
"pin" choice.

But over in pcbnew I get all pads highlighted rather than the single pad 
corresponding to
the pin.

This behaviour ain't like it used to be.  So is this broken or is there some 
other user
action required to get the pad highlighted via cross-probing.

Thanks,

Dick

___
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] GitLab migration

[Dick Hollenbeck]

> gitlab in a Docker container

Here's an on going effort which would reduce the work:

https://docs.gitlab.com/ee/install/docker.html


>some of these augmentation needs are not all foreseeable now.


>> but the real question is what is the benefit?


There are more than one benefit, and this is not the real question, because 
there are
multiple questions.

Like most things in life it is a cost benefit analysis.  That analysis cannot 
be done in
2-3 emails.


Here are some more benefits:

*) Owning your own data,
*) only having to move it once launchpad; not a second time, after the list of 
feature
voids gets so long and you then find a rabbit willing to go down into Mark's 
rabbit hole
and play house.  One man's rabbit hole is a rabbit's masterpiece. This would be 
merely
using the open source model, and pushing changes upstream.  Hopefully *we* of 
all people,
don't indict that in one sentence.


git with rebasing helps, but you knew that.  And the receptiveness of upstream 
plays a big
role in weighing the pain factor and the patch backlog.  Overall it is an 
additional
element of freedom, and yes it does come with a cost.



HTH,

Dick


___
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] GitLab migration

[Dick Hollenbeck]

On 10/14/19 1:31 AM, Dick Hollenbeck wrote:
> Is there a reason to try and host gitlab ourselves?

I would look for gitlab in a Docker container, could be easy for the experienced
volunteer.

___
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] GitLab migration

[Dick Hollenbeck]

Wayne,

Maybe this has been asked and answered, but

Is there a reason to try and host gitlab ourselves?

We have a few clever people available to augment the install with bells and 
whistles, and
some of these augmentation needs are not all forseeable now.

Improvements might be submitted upstream even...

Just wanted to make sure this has been considered.  It is not particularly 
important to me
personally, but I thought it might be worth discussing because it could solve 
some
problems down the road and lead to greater freedom.

BTW, I used KiCad again recently and you'll are doing a wonderful job on the 
enhancements.
 It was a joy to use.


Regards,

Dick




___
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

[Dick Hollenbeck]

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 know what UTF32 is.   It seems like an oxymoron.  If a 32 bit 
field can
hold every character on earth, why do you imply with the "UTF" prefix that this 
is a multi
element per character animal?  Could just be a bad name selection.  "Real 
unicode" would
have been a better name.

In any case, that class probably has some decent typedefs that make it easy to 
use, and
with some conversion functions to and from wxSring, might be easiest to deal 
with long term.

Note that wchar_t is a classic example of bad software design.  Somebody made a 
bet on
wchar_t being wider than char, but did not ensure that it was big enough.  (Did 
not gather
all the concerns up before racing forward.)

char32_t does not make that mistake.  Well it should work until we get invaded 
by space
aliens.

And really, if the next wxWidgets major release does not use this as their 
string
foundation, then I would remain more confused than I am now.  And its confusing 
how that
might be possible.

Because I bought what I would have called a super computer 12 years ago for 
under $35
recently, with a lot of ram.

Dick




___
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

[Dick Hollenbeck]

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 wxWidgets UI code.  Being
> able to use a standard C++ string implementation would (may?) go a long
> way in helping with that goal.

That goal is what I had in mind when I wrote the UTF8 class, and its 
bidirectional
conversions to and from wxString.  I think you can pass instances of UTF8 to wx 
functions
in many cases, and assign to UTF8 on function returns.

But, you don't have all the nice translation support there.  You could through 
use wx
translation support and simply assign to UTF8, however.





___
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

[Dick Hollenbeck]

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 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 around parsing the string by 
> just not doing it:
> 
> Remarks
> Note that while the behaviour of wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> when 
> |wxUSE_UNICODE_WCHAR==1| resembles
> UCS-2 encoding, it's not completely correct to refer to wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> as UCS-2 encoded 
> since you can
> encode code points outside the /BMP/ in a wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> as two code units 
> (i.e. as a
> surrogate pair; as already mentioned however wxString
> <https://docs.wxwidgets.org/trunk/classwx_string.html> will "see" them as 
> two
> different code points)
> 
> 
>> On 3 May 2019, at 16:06, John Beard > <mailto:john.j.be...@gmail.com>> wrote:
>>
>> 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 thread-unsafe.
>>
>> This is what the wxString documention recommends. Furthermore, in any 
>> Unicode string,
>> regardless of encoding (8, 16, 32), index access is almost entirely useless 
>> anyway, as
>> code units/points are only indirectly related to glyphs and/or perceived 
>> characters
>> anyway. If you need to parse a Unicode string, you must iterate from the 
>> start. There is
>> no way around it.
>>
>> If we're crashing due to cross thread access by index, the bug is probably 
>> that we
>> access the string by index at all. If this was accessed by iterator, cross 
>> thread, and
>> the string is not changed, it's fine. If the string is changed in another 
>> thread, cached
>> iterators are invalid (same as if you change an C++ container in a single 
>> thread. The
>> standard tells you what iterators are invalidated for each operation on a 
>> container).
>>
>> I may have got the wrong end of the wxStick here (I can't check it for 
>> myself right
>> now), but as far as I can tell, this is fixable by just never caching 
>> indices, as if we
>> were looking at a C-style char array, and using iterators instead.
>>
>> We should probably also turn off the unsafe string conversions by defining
>> wxNO_UNSAFE_WXSTRING_CONV, if it is not already define.
>>
>> Cheers,
>>
>> John
>>
>> On 3 May 2019 16:35:30 CEST, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>>
>> 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 wxWidgets will add/remove a pointer even for something 
>> seemingly innocuous
>> like an Empty() check.  So doing mutex locks on our side for non-const 
>> iterator
>> access is not sufficient.
>>
>> The worst part is that since two threads collide on the same string only 
>> rarely, we
>> don’t even know how many of these bugs we have.  We’ve fixed 3 or 4 of 
>> them (by
>> adding our own mutex checking on any access), but are there 0 or 10 
>> more?  Haven’t a
>> clue.
>>
>>>> It is between sad and breath taking.
>>
>> Indeed.
>>
>> Cheers,
>> Jeff.
>>
>>> On 3 May 2019, at 15:16, Dick Hollenbeck >> <mailto:d...@softplc.com>> wrote:
>>>
>>> Thanks Jeff.
>>>
>>> On 5/3/19 4:22 AM, Jeff Young wrote:
>>>> Hi Dick,
>>>>
>>>>>> h) What is 

Re: [Kicad-developers] 6.0 string proposal

[Dick Hollenbeck]

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 subset of multi-threaded source files (object file make targets), 
or the
whole shebang for maximum pain.



On 5/3/19 10:06 AM, John Beard wrote:
> 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 thread-unsafe.
> 
> This is what the wxString documention recommends. Furthermore, in any Unicode 
> string,
> regardless of encoding (8, 16, 32), index access is almost entirely useless 
> anyway, as
> code units/points are only indirectly related to glyphs and/or perceived 
> characters
> anyway. If you need to parse a Unicode string, you must iterate from the 
> start. There is
> no way around it.
> 
> If we're crashing due to cross thread access by index, the bug is probably 
> that we access
> the string by index at all. If this was accessed by iterator, cross thread, 
> and the string
> is not changed, it's fine. If the string is changed in another thread, cached 
> iterators
> are invalid (same as if you change an C++ container in a single thread. The 
> standard tells
> you what iterators are invalidated for each operation on a container).
> 
> I may have got the wrong end of the wxStick here (I can't check it for myself 
> right now),
> but as far as I can tell, this is fixable by just never caching indices, as 
> if we were
> looking at a C-style char array, and using iterators instead.
> 
> We should probably also turn off the unsafe string conversions by defining
> wxNO_UNSAFE_WXSTRING_CONV, if it is not already define.
> 
> Cheers,
> 
> John
> 
> On 3 May 2019 16:35:30 CEST, Jeff Young  wrote:
> 
> 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 wxWidgets will add/remove a pointer even for something 
> seemingly innocuous
> like an Empty() check.  So doing mutex locks on our side for non-const 
> iterator access
> is not sufficient.
> 
> The worst part is that since two threads collide on the same string only 
> rarely, we
> don’t even know how many of these bugs we have.  We’ve fixed 3 or 4 of 
> them (by adding
> our own mutex checking on any access), but are there 0 or 10 more?  
> Haven’t a clue.
> 
>>> It is between sad and breath taking.
> 
> Indeed.
> 
> Cheers,
> Jeff.
> 
>> On 3 May 2019, at 15:16, Dick Hollenbeck > <mailto:d...@softplc.com>> wrote:
>>
>> 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 it is onely *One* issue is an important data point.
>>
>> Since you know it is crashing in this class, you must know approximately 
>> where, and
>> under
>> what kind of read/write activity.  Of course, if read activity triggers 
>> a lazy
>> (deferred)
>> transformation, then this distinction can get blurred.  But more 
>> information on source
>> file locations would be very helpful to me.
>>
>> Another important data point you brought is that the wx library 
>> designers are advising
>> against using wxString for core application.  It will take a couple of 
>> hours to even
>> contemplate that, it is basically staggering to me.  It is between sad 
>> and breath
>> taking.
>> Sounds like they designed themselves into a corner and are now 
>> acknowledging that what
>> they designed is more of an API commitment that they want to disavow 
>> than a real
>> solution.
>>
>> I can see where that can happen.  Superior designs come from experience. 
>&

Re: [Kicad-developers] 6.0 string proposal

[Dick Hollenbeck]

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 solution set, without too many ripples.  But to get that 
lucky
would require knowing what the immediate problems are in more detail.


Dick


On 5/3/19 8:25 AM, Wayne Stambaugh wrote:
> 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 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.)
>>
>>
>> I've been looking at this for a few months now.  I think it is so important, 
>> that a
>> sub-committee should be formed, and if that committee takes as long as 4 
>> months to come to
>> a recommendation, this would not be too long.  This issue is simply too 
>> critical.
>>
>> I would like to volunteer to be on that committee.  For the entire list to 
>> participate in
>> this simply does not make sense to me.  I would welcome the opportunity to 
>> study this with
>> a team of 5-6 players.  More than that probably leads to anxiety.  Then, 
>> given the
>> recommendations, the list would of course have an opportunity to raise 
>> questions and take
>> shots, before a strategy is formulated, and before anything is implemented.
>>
>> Again, approximately:
>>
>>   committee recommendations -> list approval -> strategy formulation -> 
>> implementation
>>
>>
>> Up to now I have looked at many libraries and have [way *too* much] 
>> experience in multiple
>> languages on multiple platforms, so I think I can be valuable contributor.
>>
>> The final work product initially would simply be a list of recommendations, 
>> that quickly
>> transforms to a strategy thereafter.  This is an enormous undertaking, so I 
>> suggest
>> against racing to a solution.  It could look a lot easier than it will 
>> ultimately be, as
>> is typical in software development.  But the return on investment needs to 
>> be near optimal
>> in the end.
> 
> I have no intention of just winging a solution and hoping it works.  We
> are just in the very early stages of brainstorming.  We know that in the
> long run we will have to do something to improve our current handling of
> strings so carefully defining what that looks like is important.  Once
> we have a well defined strategy, implementation will be clear to all
> developers.
> 
>>
>> Some questions to answer are:
>>
>> a) How did wxString get to its current state?  Is is merely a conglomeration 
>> of after
>> thought, or is is anywhere near optimal.
>>
>> b) Why so many forms of it?  Can one form be chosen for all platforms?
>>
>> c) How does wxString it compare to QtString?
>>
>> d) What does the set of characters that don't fall into UCS2 actually look 
>> like?  How big
>> is this set, really?  (UTF16 is bigger than UCS2 and picks up the 
>> difference.)
>>
>> e) For data files, I think UTF8 is fine.  So the change is for RAM 
>> manipulation of
>> strings.  Aren't we talking about a RAM resident string that bridges into 
>> the GUI seamlessly?
> 
> UTF8 is definitely not going to change for file I/O.
> 
>>
>> f) What does new C++ language support offer?
>>
>> g) What do C++ language designers suggest?
>>
>>
>> etc.
>>
>> But this is best continued in a smaller group, as said.
> 
> I'm fine with keeping this limited to the lead dev team and yourself
> since it most likely the responsibility to implement this will fall on
> one of our shoulders.  There is no hurry on this.  Everyone has plenty
> to do as V6 development is in fu

Re: [Kicad-developers] 6.0 string proposal

[Dick Hollenbeck]

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 it is onely *One* issue is an important data point.

Since you know it is crashing in this class, you must know approximately where, 
and under
what kind of read/write activity.  Of course, if read activity triggers a lazy 
(deferred)
transformation, then this distinction can get blurred.  But more information on 
source
file locations would be very helpful to me.

Another important data point you brought is that the wx library designers are 
advising
against using wxString for core application.  It will take a couple of hours to 
even
contemplate that, it is basically staggering to me.  It is between sad and 
breath taking.
Sounds like they designed themselves into a corner and are now acknowledging 
that what
they designed is more of an API commitment that they want to disavow than a 
real solution.

I can see where that can happen.  Superior designs come from experience.  
Experience comes
with usage and time, neither of which are always available up front.





> 
> This design document makes for fascinating
> reading: https://wiki.wxwidgets.org/Development:_UTF-8_Support.  It appears 
> that the
> current wxString is at least in part modelled on QtString.
> 
> There’s also a bunch of interesting info
> here: https://docs.wxwidgets.org/trunk/overview_string.html, which I believe 
> is more
> up-to-date than the previous link.  In particular, there’s the mention that 
> wxString
> handles extra-BMP characters transparently when compiled in UTF8 mode 
> (currently used by
> Kicad), but does NOT when compiled in default mode (in which case the app 
> must handle
> surrogate pairs).  This of course directly leads to your point (d):
> 
>>>> d) What does the set of characters that don't fall into UCS2 actually look 
>>>> like?  How big
>>>> is this set, really?  (UTF16 is bigger than UCS2 and picks up the 
>>>> difference.)
> 
> Do we really need to handle extra-BMP characters?
> 
> An even more recent version of the second document
> (https://docs.wxwidgets.org/trunk/classwx_string.html) finally makes an 
> oblique reference
> to the multi-threading issue by starting with this (rather unhelpful) 
> suggestion:
> 
> Note
> While the use of wxString 
> <https://docs.wxwidgets.org/trunk/classwx_string.html> is
> unavoidable in wxWidgets program, you are encouraged to use the standard 
> string
> classes |std::string| or |std::wstring| in your applications and convert 
> them to and
> from wxString <https://docs.wxwidgets.org/trunk/classwx_string.html> only 
> when
> interacting with wxWidgets.
> 
> 
> Cheers,
> Jeff.
> 
> 
>> On 3 May 2019, at 02:03, Dick Hollenbeck > <mailto:d...@softplc.com>> wrote:
>>
>> On 5/2/19 5: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 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.)
>>>
>>>
>>> I've been looking at this for a few months now.  I think it is so 
>>> important, that a
>>> sub-committee should be formed, and if that committee takes as long as 4 
>>> months to come to
>>> a recommendation, this would not be too long.  This issue is simply too 
>>> critical.
>>>
>>> I would like to volunteer to be on that committee.  For the entire list to 
>>> participate in
>>> this simply does not make sense to me.  I would welcome the opportunity to 
>>> study this with
>>> a team of 5-6 players.  More than that probably leads to anxi

Re: [Kicad-developers] 6.0 string proposal

[Dick Hollenbeck]

On 5/2/19 5: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 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.)
> 
> 
> I've been looking at this for a few months now.  I think it is so important, 
> that a
> sub-committee should be formed, and if that committee takes as long as 4 
> months to come to
> a recommendation, this would not be too long.  This issue is simply too 
> critical.
> 
> I would like to volunteer to be on that committee.  For the entire list to 
> participate in
> this simply does not make sense to me.  I would welcome the opportunity to 
> study this with
> a team of 5-6 players.  More than that probably leads to anxiety.  Then, 
> given the
> recommendations, the list would of course have an opportunity to raise 
> questions and take
> shots, before a strategy is formulated, and before anything is implemented.
> 
> Again, approximately:
> 
>   committee recommendations -> list approval -> strategy formulation -> 
> implementation
> 
> 
> Up to now I have looked at many libraries and have [way *too* much] 
> experience in multiple
> languages on multiple platforms, so I think I can be valuable contributor.
> 
> The final work product initially would simply be a list of recommendations, 
> that quickly
> transforms to a strategy thereafter.  This is an enormous undertaking, so I 
> suggest
> against racing to a solution.  It could look a lot easier than it will 
> ultimately be, as
> is typical in software development.  But the return on investment needs to be 
> near optimal
> in the end.
> 
> Some questions to answer are:
> 
> a) How did wxString get to its current state?  Is is merely a conglomeration 
> of after
> thought, or is is anywhere near optimal.
> 
> b) Why so many forms of it?  Can one form be chosen for all platforms?
> 
> c) How does wxString it compare to QtString?
> 
> d) What does the set of characters that don't fall into UCS2 actually look 
> like?  How big
> is this set, really?  (UTF16 is bigger than UCS2 and picks up the difference.)
> 
> e) For data files, I think UTF8 is fine.  So the change is for RAM 
> manipulation of
> strings.  Aren't we talking about a RAM resident string that bridges into the 
> GUI seamlessly?
> 
> f) What does new C++ language support offer?
> 
> g) What do C++ language designers suggest?

h) What is the list of deficiencies with current string usage?


> 
> 
> etc.
> 
> But this is best continued in a smaller group, as said.
> 
> 
> The other thing that I bring to this is vast familiarity with KiCad's 
> internal workings,
> string use cases, and goals.
> 
> Let me know if I can help.
> 
> Regards,
> 
> Dick
> 
> 
> ___
> 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

[Dick Hollenbeck]

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


I've been looking at this for a few months now.  I think it is so important, 
that a
sub-committee should be formed, and if that committee takes as long as 4 months 
to come to
a recommendation, this would not be too long.  This issue is simply too 
critical.

I would like to volunteer to be on that committee.  For the entire list to 
participate in
this simply does not make sense to me.  I would welcome the opportunity to 
study this with
a team of 5-6 players.  More than that probably leads to anxiety.  Then, given 
the
recommendations, the list would of course have an opportunity to raise 
questions and take
shots, before a strategy is formulated, and before anything is implemented.

Again, approximately:

  committee recommendations -> list approval -> strategy formulation -> 
implementation


Up to now I have looked at many libraries and have [way *too* much] experience 
in multiple
languages on multiple platforms, so I think I can be valuable contributor.

The final work product initially would simply be a list of recommendations, 
that quickly
transforms to a strategy thereafter.  This is an enormous undertaking, so I 
suggest
against racing to a solution.  It could look a lot easier than it will 
ultimately be, as
is typical in software development.  But the return on investment needs to be 
near optimal
in the end.

Some questions to answer are:

a) How did wxString get to its current state?  Is is merely a conglomeration of 
after
thought, or is is anywhere near optimal.

b) Why so many forms of it?  Can one form be chosen for all platforms?

c) How does wxString it compare to QtString?

d) What does the set of characters that don't fall into UCS2 actually look 
like?  How big
is this set, really?  (UTF16 is bigger than UCS2 and picks up the difference.)

e) For data files, I think UTF8 is fine.  So the change is for RAM manipulation 
of
strings.  Aren't we talking about a RAM resident string that bridges into the 
GUI seamlessly?

f) What does new C++ language support offer?

g) What do C++ language designers suggest?


etc.

But this is best continued in a smaller group, as said.


The other thing that I bring to this is vast familiarity with KiCad's internal 
workings,
string use cases, and goals.

Let me know if I can help.

Regards,

Dick


___
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] eeschema bom plugins

[Dick Hollenbeck]

Thanks Jeff and JP!

I really appreciate your time, both of you had to dig into the config file.

I generated a BOM!

The problem with the dialog is that it uses terms without defining them.  Like, 
in the
purest sense, what is a bom plugin?

We are running an external program.  This is not really a plugin, since I can 
run any
external program.  "Bom builder" would make more UI sense.

Then, why is the interpreted data that I am feeing to a python interpreter the 
"plugin",
rather than python itself?  The *.py is consumed by python.  What if my bom 
builder was
written in C++, then why do you want to "parse" this as your plugin, just to 
throw a few
lines of text up in a dialog.  I am not a fan of this design.  The comments 
that the
(plugin header parser) ends up gleaning could have been added to the config 
file as fields
in the plugin records.


BTW, when do we get tooltips in wxWidgets on Linux?  Simple things like a few 
tooltips
would have made this email exchange unnecessary. Obviously I have used software 
before, so
when even I cannot use a dialog because of lack of clarity purpose, I'd say its 
not a
shiny dialog.

There's some feedback, if any one cares.

Again, thank you very much for your time.

Dick






On 4/29/19 6:38 AM, jp charras wrote:
>> Would be nice to generate a BOM, could do it for the last 12 years, cannot 
>> now.
>>
> Hi Dick,
> 
> I do not remember when and why the config file has changed, but I do not
> have any issue to recreate the command line from the dialog (just tested
> on Linux 14.04 and 16.04).
> This is fast.
> 
> Attached the line in eeschema config file I created by the latest
> Eeschema version for sample.
> 
> I am guessing the easier way to fix your issue is to delete old plugins
> config lines and recreate them.




___
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] eeschema bom plugins

[Dick Hollenbeck]

Folks,

Today I tried to create a BOM from eeschema using a plugin command line that 
had been
working for about 8 years.  I need information on this new interface.  Either 
it is broken
or I am missing the intended set of goals and intentions.  So documentation on 
the latter
would be nice.  Otherwise I am leaning towards the conclusion that this is 
fully broken.

Coming from an older version, I have a file


~/.config/kicad/eeschema


In there is a keyword "bom_plugins".

The new parser is not parsing the old string, the symptom of that is that the 
plugin's
m_name comes up blank.  Fine, another path forward is to blow away the entire 
value of
that bom_plugins keyword and start over.  I tried that, and the user interface 
is fully
non-intuitive and I simply could not find my way through that simple dialog.

So I am stuck.

Here is my old bom_plugins string, which as I said did not parse, I stepped 
through it
with the debugger and the m_name field on the first Grouped_By_Value came up 
empty,
because now it thinks the PLUGINs constructor takes a filename.  The user 
manual is fully
empty on this new interface.

HELP.

Here is the value of the config file, shown on multiple lines, although in the 
config file
mentioned above it is on a single line.

(plugins
(plugin Grouped_By_Value
(cmd "/usr/bin/python  /i/pcbs/bom_scripts/bom_csv_grouped_by_value.py  \\"%I\\"
\\"%P/B.BOM.csv\\""))
(plugin "Debug Plugins" (cmd "/bin/sh -c 'echo \\"%I\\"  \\"%B %O %P\\" >
/tmp/snag-command-line.txt'"))
)

Would be nice to generate a BOM, could do it for the last 12 years, cannot now.


___
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] kicad_pcb, kicad_mod format change for daily build?

[Dick Hollenbeck]

On 4/15/19 8:50 AM, jp charras wrote:
> Le 15/04/2019 à 15:34, Jeff Young a écrit :
>> Yes, this was intentional.  It allows users to put things like spaces in 
>> layer names and other user-editable things.
>>
>> I’ll fix up the STEP exporter….
>>
>>> On 15 Apr 2019, at 13:56, easyw  wrote:
>>>
>>> Hi,
>>> recently I have noticed that both kicad_pcb and kicad_mod seems to have 
>>> changed their format.
>>> It have been introduced double quotes for layers pads etc.
>>> Is that necessary or intentional?
>>>
>>> Here two related issues links:
>>> footprint
>>> https://github.com/easyw/kicadStepUpMod/issues/13#issuecomment-481160108
>>> pcb
>>> https://forum.kicad.info/t/bad-layer-data-error-when-exporting-step/16322/11
>>>
>>> and a small diff example:
>>>
>>> (layers
>>>(0 F.Cu signal)
>>>(31 B.Cu signal)
>>>
>>> (layers
>>>(0 "F.Cu" signal)
>>>(31 "B.Cu" signal)
>>>
>>> Thanks
>>> Maurice
> 
> Exactly, in these files, user strings (like fields, pad names, layer
> names...) were previously quoted on request, i.e. if they contained a
> space or some other special delimiter char.
> 
> Now they are always quoted, which is better: user strings are always
> clearly identified.
> This is not really a format change.

JP, I think you are blending syntax with grammar.   I do not understand the 
need for this
change and currently do not agree with it.  It creates noise in version control 
systems,
and makes the files bigger, for no real gain.

The save functions have always done a nice job of deciding whether a quote is 
necessary.
At this pace the files will end up looking like javascript before long, and 
will be noisy.

Dick

___
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] New Project Leader

[Dick Hollenbeck]

Ladies and Gentlemen:

With great respect and humility I am turning over KiCad project leadership to

   Mr. Wayne Stambaugh.

Wayne has established himself as a seasoned leader and software architect.

His software architectural skills and leadership skills make him in my opinion 
the best of
available persons to fill this role.  We should hope and wish that he finds the 
job
rewarding and fulfilling in a way that leads to an extended term in this 
volunteer position.

I obviously have confidence in his abilities, but I don't over estimate his 
staying power,
nor should you.  Please be kind and respectful to him.


It is time for me to move out of the top spot and off the mailing list.



I want to acknowledge Brian Sidebotham with special thanks for his faith in my 
leadership
and his exceptional contributions in the realm of KiCad Winbuilder.  It was his 
faith in
my vision that motivated him to do an unspeakable volunteer effort from which 
hundreds of
KiCad users benefit.  While I thank him for his confidence in that vision of 
mine, you all
should thank him for his actual time and leadership in making KiCad on Windows 
worth
using.  His efforts in promoting CMake as a build engine warrant industry and 
world-wide
acclaim and he is due a bonus from Kitware.


I want to acknowledge and thank Fabrizio Tappero, who's graphics/icons, and 
user manual
efforts should go down as some of the most important contributions in KiCad's 
history.


I want to acknowledge and thank Carl Poirier who is overseeing what is quickly 
becoming a
world-wide resource.  At my egging, he stepped up and is now overseeing what is 
becoming
something truly exceptional along with the efforts of generous contributors.  I 
wish him
the best, I encourage him to be a leader and encourager among reluctant 
volunteers. I am
proud to have been an inspiration in something that he can proudly put on his 
resume some day.


I want to thank Javier Serano, whose confidence in our project direction and 
leadership
inspired him to join and bring in some additional world class talent and team 
players, Tom
and Orson, as well as KiCad team leadership and seasoned experience.


Lastly I want to thank Jean-Pierre for his friendship, for his faith and 
confidence in my
sometimes loud and brash leadership.  But were it not for his stabilizing 
influence in all
things KiCad, we'd all be making less PCB boards, or doing them more 
expensively.


Please take care of my good friend Wayne Stambaugh.  I have prayed with Wayne, 
I know his
son.  You could not have a better man at the helm.


Appreciation goes a long way towards keeping this project healthy, and for it 
to be
healthy you need a class act at the top, you have one in Wayne.


Dick


P.S.

*) The project has SoftPLC Corporation's permission to re-license its 
copyrights under GPL3.

*) When somebody other than superman Jean-Pierre surpasses this number of 
commits:
   $ bzr log | grep 'dickelbeck\|Hollenbeck' | wc -l
send me a personal note and I'll send him a congratulatory memo.  :)

*) It would be nice if the kicad-pcb.org website listed SoftPLC Corporation as a
historically significant corporate sponsor.


Out.



___
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] KiCad build.

[Dick Hollenbeck]

On 08/21/2014 04:38 PM, Jon Neal wrote:
> Looking from the outside that is very aggressive, harsh, and childish. I 
> thought you were
> stepping away from the project Dick (At least that is what you said a few 
> weeks ago).


Jon,

Your uninformed opinion will have no effect on the SoftPLC policy.  In fact, I 
won't even
bring up your opinion at my SoftPLC Corporation's board of director's meeting, 
nor at the
corporation's share holder's meeting.  Because I can already anticipate what 
they would say:


"Dick, we invested in your company in order to make a profit.  Every minute you 
spend on
KiCad is a minute you are not making product to improve sales and enhance 
profits and our
return on investments.  It's clear to us that your recent 41,000 line and 
21,000 line
patches are unheard of and with Jon's comments, it is clear that they are under
appreciated and not instantaneously enhancing corporate goodwill.  So there's no
justifiable reason, from a business standpoint for you to continue.  KiCad is 
good enough
now for our own corporate use.  Every minute you spend on KiCad is lost 
opportunity cost
to the corporation."

"However, those copyrights in KiCad are our corporate assets.  We view them as 
providing
corporate goodwill long term.  They establish corporate competency, corporate 
visibility,
and may in the long run lead to other kinds of business.  You did the right 
thing in
sending a message that the corporation intends to defend the copyrights 
rigorously, either
inside the project or out.  You also put into place a filter which prefers like 
minded
code contributors who know how to be respectful of prior ownership investments 
and also
value their own copyrights and would make good alliance partners in the event 
of some kind
of project wide code theft."

"It should be enough that the code is licensed under a license which allows 
respectful end
user use.  However, we live in a world where personal and corporate character 
seem to be
deteriorating."

"Sending an early warning signal may have allowed the corporation to avoid 
lawsuits in the
future, while at the same time signalling that SoftPLC Corporation is a viable 
alliance
partner in defending the collective KiCad copyrights."

"You did the right thing, but its time for you to focus on product development. 
 You have
made KiCad sufficiently good for our own internal corporate use, and it is 
clear your time
is better spent focusing on product development."


And at that point the most I could say would be, "well Jon thought his point of 
view was
important enough to get thrown off the mailing list.  So I owed him that."



> Maybe it is best to let more than just yourself offer an opinion on this.

See above.


> Is there a reason ANY of the code in KiCad is copyright anyone except KiCad 
> itself? Other
> projects I have worked on did not allow copyright by anyone except for the 
> project itself.

See above.


Jon, here you have offered an opinion first, and sought knowledge second.
Please don't vote that way.As we're seeing in the U.S. now, this can only 
lead to bad
things.

You will be let you back on the developer's list in a couple of weeks if you 
promise to go
read about how the GPL works and the importance of corporate sponsors in an 
open source
project.

Generally however, this mailing list is for code contributors.  
Non-contributors who come
in here with critical points of view have been thrown out before.  The recourse 
is for the
developers to do everything by private email, and I don't think that is what is 
best for
the project.

As Cirilo accurately stated, code contributors are ownership share holders in 
this
project.  Mere lurkers and users are not, so they have no standing on this 
mailing list.





>>
>> Jon Neal
>>
>> On Aug 21, 2014 9:56 AM, "Dick Hollenbeck" > <mailto:d...@softplc.com>>
> wrote:
>>>
>>> On 08/21/2014 07:57 AM, Michael Narigon wrote:
>>> > OK, thanks for your comment.  Michael
>>>
>>> Actually I'm not done:
>>>
>>> Neither the KiCad project, nor SoftPLC Corporation will tolerate the 
>>> removal of copyright
>>> messages unless either a) authorized by the copyright holder or b) 
>>> incorrectly placed in
>>> the first place, irrespective of opined legality of such removal.  It will 
>>> not be
> tolerated.
>>>
>>>
>>> Historically, it has not been tolerated because it has never before 
>>> happened.  Now that it
>>> has happened, this statement needed to be made.
>>>
>>>
>>> Michael has been removed from the project mailing list (after having been 
>>> given a chance
>>> to offer immediate 

Re: [Kicad-developers] KiCad build.

[Dick Hollenbeck]

On 08/21/2014 07:57 AM, Michael Narigon wrote:
> OK, thanks for your comment.  Michael

Actually I'm not done:

Neither the KiCad project, nor SoftPLC Corporation will tolerate the removal of 
copyright
messages unless either a) authorized by the copyright holder or b) incorrectly 
placed in
the first place, irrespective of opined legality of such removal.  It will not 
be tolerated.


Historically, it has not been tolerated because it has never before happened.  
Now that it
has happened, this statement needed to be made.


Michael has been removed from the project mailing list (after having been given 
a chance
to offer immediate correction), as will anyone who challenges this stance.


Dick


___
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] KiCad build.

[Dick Hollenbeck]

On 08/20/2014 05:07 PM, Michael Narigon wrote:
> Gents,
> It probably landed in your spam filter (half the e-mails from the developers 
> list do to me) but I sent a message that I am pretty far along on what you 
> are discussing. See the tar file at https://code.launchpad.net/~mnarigon.
> 
> I used the good work you guys had and cleaned it up. I used the 
> kicad-build.sh concept of the build steps (and KiCadOSXBuilder) and separated 
> out the KiCad build process into a number of steps that can be selectively 
> executed. For those platforms where the dependencies exist I take advantage 
> of them.
> 
> The steps are roughly check the environment, check for pre-requisites, build 
> tools, build dependent libraries, pull source from the repository, build, 
> install, and package.
> 
> The scripts are alpha but the steps I have completed are pretty robust. I am 
> still working on the install and packaging steps, debug builds do not work, 
> and I have not yet worked on windows other than to check the cygwin 
> dependencies although I intend these script to fully support Windows.
> 
> Currently, I can build KiCad on OS X and Linux. I am currently focussed on 
> getting a drag and drop install working on OS X.
> 
> In the tar there is the top-level build script called build.sh. Read this to 
> understand what is going on, and try it out by running it.
> 
> I intend this to work on OS X, Linux (debian and Redhat) and Windows.
> 
> Michael




scripts/CMakeLists-pcbnew-github.txt.in


Why is this now somebody else's copyright?

That was actually my fucking work.

Your license is incompatible with the project.

You only have one chance to make a first impression.

Yours has been made.



___
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] KiCad build.

[Dick Hollenbeck]

On 08/20/2014 11:45 AM, Wayne Stambaugh wrote:
> On 8/19/2014 5:17 PM, Dick Hollenbeck wrote:
>> On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
>>> On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
>>>> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
>>>>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>>>>>> On 16 August 2014 17:44, Wayne Stambaugh  wrote:
>>>>>>> One of the tasks that I have committed to working on in the KiCad road
>>>>>>> map is to clean up the current mess we have created by allowing
>>>>>>> dependency libraries to be built as part of the KiCad source build.  The
>>>>>>> only exception I see for the time being is Boost.  Although I am have my
>>>>>>> reservations on that as well.  Why you ask?  I've spent several days
>>>>>>> trying to get KiCad to build on Windows using MSYS2 as my build
>>>>>>> environment and mingw64 as my target environment.  Every single library
>>>>>>> dependency with the exception of our custom Boost and avhttp (which
>>>>>>> could easily be build and installed using CMake) are already packaged
>>>>>>> for me.  However, the current KiCad build insists on downloading and
>>>>>>> building some libraries from source that are already installed.  This is
>>>>>>> silly.  I can resolve the issues by passing all of the
>>>>>>> PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my
>>>>>>> build environment already points the correct path.
>>>>>>>
>>>>>>> Originally I intended to create a separate project to build the KiCad
>>>>>>> library dependencies but I have since changed my mind.  I do *not* think
>>>>>>> it is asking too much of developers to learn how to build and/or install
>>>>>>> libraries on their preferred platform.  If as a developer you must have
>>>>>>> this done for you automatically, I am going to please ask that *you*
>>>>>>> create a separate platform specific build tool such as the excellent
>>>>>>> kicad-winbuilder that Brian has created.  This will significantly
>>>>>>> simplify the KiCad CMake files and eliminate the situation I described
>>>>>>> above.  My preference and goal is that the KiCad CMake files be used to
>>>>>>> build KiCad, not library dependencies.
>>>>>>>
>>>>>>> Initially, I plan to remove the dependencies that do not require any
>>>>>>> patching to build which currently are avhttp, swig, cairo, libpng,
>>>>>>> pixman, pcre, pkgconfig, and glew.  Then I will remove the dependencies
>>>>>>> with platform specific patches which are openssl, wxwidgets and
>>>>>>> wxpython.  Then I will try to figure out what to do with the problem
>>>>>>> child that is Boost.  I would also suggest that all platform specific
>>>>>>> library dependency build patches be remove as well leaving only the
>>>>>>> Boost patches that are required for all platforms (except the context
>>>>>>> switching patches).
>>>>>>>
>>>>>>> My goal here is not to step on anyone's toes it is to get our build
>>>>>>> system under control so that I can build *KiCad* rather than figure out
>>>>>>> how to get the dependencies to build or not as the platform dictates.  I
>>>>>>> expect our code to be well designed and I don't think expecting the same
>>>>>>> from our build system design is out of line.  If any one has major
>>>>>>> objections then we will have to figure something out because I am not
>>>>>>> going to continue to spend valuable time fighting our build tools to get
>>>>>>> them to properly use the dependencies already installed on my platform.
>>>>>>>
>>>>>>> Wayne
>>>>>>>
>>>>>>
>>>>>> Hi Wayne,
>>>>>>
>>>>>> I think that sounds like a sane decision, although of course KiCad
>>>>>> will be subject to the bugs in other libraries, but it's up to
>>>>>> distribution maintainers to sort those out in my opinion.
>>>>>>
>>>>>> I hope that we can use some sort of de

Re: [Kicad-developers] eeschema modular kicad work

[Dick Hollenbeck]

On 08/20/2014 08:14 AM, Brian Sidebotham wrote:
>> Hi guys,
>>
>> Sorry for asking dumb questions, but what is this whole QuasiModal stuff
>> for?
>>
>> Tom
> 
> Hi Tom,
> 
> No question is dumb.
> 
> See Yann's description (from earlier in this thread) of the problem
> below, to which Quaimodal is a good solution.
> 
> Best Regards,
> 
> Brian.


Additional information is found by grepping for

"Quasi-Modal Mode Explained:"

in the source.

Its genesis was the unsightly wxSemaphore noise sprinkled about.

You could also grep the bzr log for quasi modal, back up one or two versions 
from its
first mention, then check out that version and look for wxSemaphore.

It currently serves two distinct purposes.




___
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] FreeRouting project future and kicad?

[Dick Hollenbeck]

On 08/19/2014 04:17 PM, Mário Luzeiro wrote:
> I was trying to run the FreeRouting in KiCad and It is not working (I was 
> running it some 5 weeks ago..)
> Then I found that sad litigation story:/ I really don't understand that 
> companies and what they are afraid of :|
> 
> Are already any plans / discussing how KiCad will deal with this situation? 
> ... I miss the FreeRouting!


$ java -jar FreeRouting.jar

works for me




___
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] KiCad build.

[Dick Hollenbeck]

On 08/19/2014 03:37 PM, Wayne Stambaugh wrote:
> On 8/19/2014 4:17 PM, Dick Hollenbeck wrote:
>> On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
>>> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>>>> On 16 August 2014 17:44, Wayne Stambaugh  wrote:
>>>>> One of the tasks that I have committed to working on in the KiCad road
>>>>> map is to clean up the current mess we have created by allowing
>>>>> dependency libraries to be built as part of the KiCad source build.  The
>>>>> only exception I see for the time being is Boost.  Although I am have my
>>>>> reservations on that as well.  Why you ask?  I've spent several days
>>>>> trying to get KiCad to build on Windows using MSYS2 as my build
>>>>> environment and mingw64 as my target environment.  Every single library
>>>>> dependency with the exception of our custom Boost and avhttp (which
>>>>> could easily be build and installed using CMake) are already packaged
>>>>> for me.  However, the current KiCad build insists on downloading and
>>>>> building some libraries from source that are already installed.  This is
>>>>> silly.  I can resolve the issues by passing all of the
>>>>> PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my
>>>>> build environment already points the correct path.
>>>>>
>>>>> Originally I intended to create a separate project to build the KiCad
>>>>> library dependencies but I have since changed my mind.  I do *not* think
>>>>> it is asking too much of developers to learn how to build and/or install
>>>>> libraries on their preferred platform.  If as a developer you must have
>>>>> this done for you automatically, I am going to please ask that *you*
>>>>> create a separate platform specific build tool such as the excellent
>>>>> kicad-winbuilder that Brian has created.  This will significantly
>>>>> simplify the KiCad CMake files and eliminate the situation I described
>>>>> above.  My preference and goal is that the KiCad CMake files be used to
>>>>> build KiCad, not library dependencies.
>>>>>
>>>>> Initially, I plan to remove the dependencies that do not require any
>>>>> patching to build which currently are avhttp, swig, cairo, libpng,
>>>>> pixman, pcre, pkgconfig, and glew.  Then I will remove the dependencies
>>>>> with platform specific patches which are openssl, wxwidgets and
>>>>> wxpython.  Then I will try to figure out what to do with the problem
>>>>> child that is Boost.  I would also suggest that all platform specific
>>>>> library dependency build patches be remove as well leaving only the
>>>>> Boost patches that are required for all platforms (except the context
>>>>> switching patches).
>>>>>
>>>>> My goal here is not to step on anyone's toes it is to get our build
>>>>> system under control so that I can build *KiCad* rather than figure out
>>>>> how to get the dependencies to build or not as the platform dictates.  I
>>>>> expect our code to be well designed and I don't think expecting the same
>>>>> from our build system design is out of line.  If any one has major
>>>>> objections then we will have to figure something out because I am not
>>>>> going to continue to spend valuable time fighting our build tools to get
>>>>> them to properly use the dependencies already installed on my platform.
>>>>>
>>>>> Wayne
>>>>>
>>>>
>>>> Hi Wayne,
>>>>
>>>> I think that sounds like a sane decision, although of course KiCad
>>>> will be subject to the bugs in other libraries, but it's up to
>>>> distribution maintainers to sort those out in my opinion.
>>>>
>>>> I hope that we can use some sort of deprecation system, please mark a
>>>> lib as being deprecated so that I can sort out Winbuilder before the
>>>> CMake system is broke. It's much easier to work that way round as
>>>> opposed to a reactionary approach where we break everything and then
>>>> everyone has to fix their build before being able to do anything. I
>>>> will do the leg work to keep the Winbuilder people happy and do any
>>>> projects necessary to package dependencies required by it.
>>>
>>> I will be ma

Re: [Kicad-developers] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/19/2014 03:16 PM, Vesa Solonen wrote:
> 19/08/14, 21:35, Wayne Stambaugh kirjoitti:
>> On 8/19/2014 1:53 PM, Dick Hollenbeck wrote:
> 
>>> If I have part 'R' in mylib, and it is also in library devices, it shows me 
>>> devices as my
>>> top and only candidate as I type in 'R'.
>>>
>>
>> If the picker can select part R from a library further down the library
>> stack, that's not the one that will be shown in the schematic.
> 
> It would be really nice if any of the instances could be picked by the
> picker. Then pushing that picked one to library-cache and updating the
> schematic from the cache just updated. Wouldn't that solve the whole
> case cleanly?

No.  The library name is not recorded in the schematic next to the referenced 
part.  It is
not there.  In pcbnew we have "mylib:footprint".  In eeschema you only have 
"partname".

So the "lookup" of "partname" inherently only uses the library names list, 
period.

This is not going to change until it is changed.  Pcbnew is an example of how 
to do it.

Moreover, the problem in eeschema is more critical than it was in pcbnew.  In 
pcbnew
footprints are copied.  So even if you forget where one came from, its still in 
the board.

Not so in eeschema.  If you change your library names list, you can see a 
different
library part being referenced from the schematic component.

The cache-library is just another library, it is a fallback only, not a front 
runner.

Dick




> Nag dialogs are the usability horror IMO, they break the
> workflow and need attention to clear. Just a log messge would be
> preferred by me.
> 
> Btw, it's nice to see Dick making KiCad better again. Thanks (to Wayne
> as well)!
> 
> -Vesa
> 
> 
> ___
> 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] KiCad build.

[Dick Hollenbeck]

On 08/18/2014 06:47 PM, Wayne Stambaugh wrote:
> On 8/18/2014 6:45 PM, Brian Sidebotham wrote:
>> On 16 August 2014 17:44, Wayne Stambaugh  wrote:
>>> One of the tasks that I have committed to working on in the KiCad road
>>> map is to clean up the current mess we have created by allowing
>>> dependency libraries to be built as part of the KiCad source build.  The
>>> only exception I see for the time being is Boost.  Although I am have my
>>> reservations on that as well.  Why you ask?  I've spent several days
>>> trying to get KiCad to build on Windows using MSYS2 as my build
>>> environment and mingw64 as my target environment.  Every single library
>>> dependency with the exception of our custom Boost and avhttp (which
>>> could easily be build and installed using CMake) are already packaged
>>> for me.  However, the current KiCad build insists on downloading and
>>> building some libraries from source that are already installed.  This is
>>> silly.  I can resolve the issues by passing all of the
>>> PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my
>>> build environment already points the correct path.
>>>
>>> Originally I intended to create a separate project to build the KiCad
>>> library dependencies but I have since changed my mind.  I do *not* think
>>> it is asking too much of developers to learn how to build and/or install
>>> libraries on their preferred platform.  If as a developer you must have
>>> this done for you automatically, I am going to please ask that *you*
>>> create a separate platform specific build tool such as the excellent
>>> kicad-winbuilder that Brian has created.  This will significantly
>>> simplify the KiCad CMake files and eliminate the situation I described
>>> above.  My preference and goal is that the KiCad CMake files be used to
>>> build KiCad, not library dependencies.
>>>
>>> Initially, I plan to remove the dependencies that do not require any
>>> patching to build which currently are avhttp, swig, cairo, libpng,
>>> pixman, pcre, pkgconfig, and glew.  Then I will remove the dependencies
>>> with platform specific patches which are openssl, wxwidgets and
>>> wxpython.  Then I will try to figure out what to do with the problem
>>> child that is Boost.  I would also suggest that all platform specific
>>> library dependency build patches be remove as well leaving only the
>>> Boost patches that are required for all platforms (except the context
>>> switching patches).
>>>
>>> My goal here is not to step on anyone's toes it is to get our build
>>> system under control so that I can build *KiCad* rather than figure out
>>> how to get the dependencies to build or not as the platform dictates.  I
>>> expect our code to be well designed and I don't think expecting the same
>>> from our build system design is out of line.  If any one has major
>>> objections then we will have to figure something out because I am not
>>> going to continue to spend valuable time fighting our build tools to get
>>> them to properly use the dependencies already installed on my platform.
>>>
>>> Wayne
>>>
>>
>> Hi Wayne,
>>
>> I think that sounds like a sane decision, although of course KiCad
>> will be subject to the bugs in other libraries, but it's up to
>> distribution maintainers to sort those out in my opinion.
>>
>> I hope that we can use some sort of deprecation system, please mark a
>> lib as being deprecated so that I can sort out Winbuilder before the
>> CMake system is broke. It's much easier to work that way round as
>> opposed to a reactionary approach where we break everything and then
>> everyone has to fix their build before being able to do anything. I
>> will do the leg work to keep the Winbuilder people happy and do any
>> projects necessary to package dependencies required by it.
> 
> I will be making changes very slowly because I expect there to be some
> breakage with some of the FindFoo.cmake changes I'm going to make.  This
> will give everyone time to respond should I break anything.  I will be
> pushing hard against adding personal install paths to every
> FindFoo.cmake file.  CMake knows how to find the correct default paths
> on most platforms and I will always give the developer the chance to
> override those using either and environment variable or a definition on
> the CMake command line for custom library testing.  I will start out
> with the dependencies that don't require any patches to build and then
> address the more complex ones like wxWidgets and finish up with the
> nightmare that is Boost.  If I change more than one FindFoo.cmake every
> two weeks, that will be a blistering pace.  The goal is to get each
> dependency test working and properly designed before moving to the next one.
> 
> Cheers,
> 
> Wayne


The current thinking among those using CMake for several large projects is that 
it can
either find or it can build in the first pass.  It struggles with finding a 
prerequisite
and building the prerequisite as a fallback, then 

Re: [Kicad-developers] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

If it weren't for the part picker issue, which I rate as my personal most 
annoying issue
in rev 5083, I would say that 5083 is the best version of KiCad that I have 
ever seen or used.

I uncorked the stop in kicad-install.sh, so that anyone who now builds using 
that script
is now back on the leading edge of features.

(This probably produces a tenfold increase in testers, and as a result maybe we 
find a
little bug here or there yet, but I doubt seriously I'll have to reverse my 
supposition
above.)


Dick


In comparison, the stable version is fools gold, but I repeat myself.

___
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] old pcbnew file format in bitmap2component tool

[Dick Hollenbeck]

On 08/19/2014 05:00 AM, Cirilo Bernardo wrote:
> While working on the bitmap2component tool to add support for
> placing bitmaps onto the planned Underlay 1/2 layers I noticed
> that the deprecated *.emp export format is still supported by
> the tool. If there are no objections I'll remove that option
> as part of my work on this feature. Given the way KiCad and
> pcbnew in particular has worked for almost a year and the more
> recent introduction of more layers, I don't see a need to
> maintain the ability to import images to the older format.


No reason to remain emp-athic to that format.



___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/19/2014 01:35 PM, Wayne Stambaugh wrote:
> On 8/19/2014 1:53 PM, Dick Hollenbeck wrote:
>> On 08/19/2014 07:33 AM, Wayne Stambaugh wrote:
>>> On 8/18/2014 5:46 PM, Dick Hollenbeck wrote:
>>>>
>>>>>> I will do the "workaround" reordering of my libraries.. not a problem 
>>>>>> for me now that I know how it works..
>>>>>
>>>>>
>>>>> I think the sort() call has to go, so I now think you discovered 
>>>>> something.
>>>>>
>>>>> Should have a fix in minutes.
>>>>>
>>>>> When the foundations get simpler, so do the algorithms.
>>>>>
>>>>>
>>>>> Dick
>>>>
>>>>
>>>> This one simplifies everything by removing the sort() and the sortOrder 
>>>> support.   The
>>>> library list is loaded in the proper order, I know of no reason to sort it.
>>>>
>>>> Guys please try this one instead of other, and comment.
>>>>
>>>> It is even simpler yet, and gets rid of the sort-order global which *would 
>>>> not fly* in a
>>>> multiple project situation.
>>>>
>>>>
>>>> Dick
>>>>
>>>
>>> Dick,
>>>
>>> That fixed it.  Thanks again for the quick response.
>>>
>>> Wayne
>>
>>
>> I committed that.
>>
>> There is still a design flaw in the part picker.
>>
>> It does not consider the current nature of how parts are actually chosen by 
>> eeschema.
> 
> It looks like the sorting needs to be eliminated from the part picker
> dialog in order to yield the correct part in the schematic even though
> it will not be as nice to use.  Otherwise we are right back to the same
> problem.  I'm surprised this issue hasn't been raised before now.
> 
>>
>> If I have part 'R' in mylib, and it is also in library devices, it shows me 
>> devices as my
>> top and only candidate as I type in 'R'.
>>
> 
> If the picker can select part R from a library further down the library
> stack, that's not the one that will be shown in the schematic.  Maybe as
> a stop gap measure we should check for duplicate part names in the
> picker and warn the user that part FOO in library BAR will be used but
> there is also a part FOO in library BAZ that may be the part they want
> and that the library search order must be changed in order to use the
> part FOO from library BAZ.


My problem is not when I choose a library and then a part.  My problem is when 
I type the
initial letters of the part name.

Yours is an OK solution for the guy who picks the library then the part within 
it.  This
is not the problem I have.

Your is not a good solution for my problem.   So lets think in terms of two 
problems.

If the part named 'R' is what I want, and there is no friggin way for me to 
select
anything but the 'R' returned via the search path, then the non selectable 'R' 
should not
be what is shown.  Then I can sidestep the warning.

If you want a nag warning for the second case, that would be fine.  Ultimately 
the UI may
be re-usable after there is a sane part lookup strategy.  But currently is does 
not match
with the real part lookup strategy allowed.

The type-ahead lookup needs to mimic the part lookup strategy. This is a 
partial re-write
and redesign, not just a nag window for my 'type-ahead' case.




___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/19/2014 07:33 AM, Wayne Stambaugh wrote:
> On 8/18/2014 5:46 PM, Dick Hollenbeck wrote:
>>
>>>> I will do the "workaround" reordering of my libraries.. not a problem for 
>>>> me now that I know how it works..
>>>
>>>
>>> I think the sort() call has to go, so I now think you discovered something.
>>>
>>> Should have a fix in minutes.
>>>
>>> When the foundations get simpler, so do the algorithms.
>>>
>>>
>>> Dick
>>
>>
>> This one simplifies everything by removing the sort() and the sortOrder 
>> support.   The
>> library list is loaded in the proper order, I know of no reason to sort it.
>>
>> Guys please try this one instead of other, and comment.
>>
>> It is even simpler yet, and gets rid of the sort-order global which *would 
>> not fly* in a
>> multiple project situation.
>>
>>
>> Dick
>>
> 
> Dick,
> 
> That fixed it.  Thanks again for the quick response.
> 
> Wayne


I committed that.

There is still a design flaw in the part picker.

It does not consider the current nature of how parts are actually chosen by 
eeschema.

If I have part 'R' in mylib, and it is also in library devices, it shows me 
devices as my
top and only candidate as I type in 'R'.



___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

>> I will do the "workaround" reordering of my libraries.. not a problem for me 
>> now that I know how it works..
> 
> 
> I think the sort() call has to go, so I now think you discovered something.
> 
> Should have a fix in minutes.
> 
> When the foundations get simpler, so do the algorithms.
> 
> 
> Dick


This one simplifies everything by removing the sort() and the sortOrder 
support.   The
library list is loaded in the proper order, I know of no reason to sort it.

Guys please try this one instead of other, and comment.

It is even simpler yet, and gets rid of the sort-order global which *would not 
fly* in a
multiple project situation.


Dick

=== modified file 'eeschema/class_library.cpp'
--- eeschema/class_library.cpp	2014-08-13 20:28:54 +
+++ eeschema/class_library.cpp	2014-08-18 21:42:33 +
@@ -53,51 +53,6 @@
 "This may cause some unexpected behavior when loading components into a schematic." )
 
 
-bool operator==( const PART_LIB& aLibrary, const wxString& aName )
-{
-// See our header class_libentry.h for function Cmp_KEEPCASE().
-return Cmp_KEEPCASE( aLibrary.GetName(), aName ) == 0;
-}
-
-
-bool operator!=( const PART_LIB& aLibrary, const wxString& aName )
-{
-return !( aLibrary == aName );
-}
-
-
-wxArrayString PART_LIBS::s_libraryListSortOrder;
-
-
-bool operator<( const PART_LIB& aItem1, const PART_LIB& aItem2 )
-{
-// The cache library always is sorted to the end of the library list.
-if( aItem2.IsCache() )
-return true;
-
-if( aItem1.IsCache() )
-return false;
-
-// If the sort order array isn't set, then sort alphabetically except.
-if( PART_LIBS::GetSortOrder().IsEmpty() )
-return Cmp_KEEPCASE( aItem1.GetName(), aItem2.GetName() ) < 0;
-
-int i1 = PART_LIBS::GetSortOrder().Index( aItem1.GetName(), false );
-int i2 = PART_LIBS::GetSortOrder().Index( aItem2.GetName(), false );
-
-if( i1 == wxNOT_FOUND && i2 == wxNOT_FOUND )
-return true;
-
-if( i1 == wxNOT_FOUND && i2 != wxNOT_FOUND )
-return false;
-
-if( i1 != wxNOT_FOUND && i2 == wxNOT_FOUND )
-return true;
-
-return ( i1 - i2 ) < 0;
-}
-
-
 PART_LIB::PART_LIB( int aType, const wxString& aFileName ) :
 // start @ != 0 so each additional library added
 // is immediately detectable, zero would not be.
@@ -873,19 +828,11 @@
 
 PART_LIB* PART_LIBS::FindLibrary( const wxString& aName )
 {
-#if 0
-BOOST_FOREACH( PART_LIB& lib, *this )
-{
-if( lib == aName )
-return &lib;
-}
-#else
 for( PART_LIBS::iterator it = begin();  it!=end();  ++it )
 {
-if( *it == aName )
+if( it->GetName() == aName )
 return &*it;
 }
-#endif
 
 return NULL;
 }
@@ -1057,7 +1004,6 @@
 wxFileName  fn;
 wxStringfilename;
 wxStringlibs_not_found;
-wxArrayString   sortOrder;
 SEARCH_STACK*   lib_search = aProject->SchSearchS();
 
 #if defined(DEBUG) && 1
@@ -1147,18 +1093,8 @@
 UTF8( libs_not_found ), 0, 0 );
 }
 
-// Put the libraries in the correct order.
-PART_LIBS::SetSortOrder( sortOrder );
-
-sort();
-
 #if defined(DEBUG) && 1
-printf( "%s: sort order:\n", __func__ );
-
-for( size_t i = 0; i < sortOrder.GetCount(); i++ )
- printf( " %s\n", TO_UTF8( sortOrder[i] ) );
-
-printf( "%s: actual order:\n", __func__ );
+printf( "%s: lib_names:\n", __func__ );
 
 for( PART_LIBS::const_iterator it = begin(); it < end(); ++it )
 printf( " %s\n", TO_UTF8( it->GetName() ) );

=== modified file 'eeschema/class_library.h'
--- eeschema/class_library.h	2014-08-13 20:28:54 +
+++ eeschema/class_library.h	2014-08-18 21:36:19 +
@@ -103,8 +103,6 @@
  */
 class PART_LIBS : public PART_LIBS_BASE, public PROJECT::_ELEM
 {
-static wxArrayString s_libraryListSortOrder;
-
 public:
 
 static int s_modify_generation; ///< helper for GetModifyHash()
@@ -226,21 +224,9 @@
 
 int GetLibraryCount() { return size(); }
 
-static void SetSortOrder( const wxArrayString& aSortOrder )
-{
-s_libraryListSortOrder = aSortOrder;
-}
-
-static wxArrayString& GetSortOrder()
-{
-return s_libraryListSortOrder;
-}
 };
 
 
-bool operator<( const PART_LIB& item1, const PART_LIB& item2 );
-
-
 /**
  * Class PART_LIB
  * is used to load, save, search, and otherwise manipulate

___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/18/2014 04:26 PM, Mário Luzeiro wrote:
> Hi Dick,
> 
> Thanks for your explanations.
> This is fun, considering the years I am using kicad and only now find this 
> situation :)
> 
> I was right now checking the project files looking for the libraries and I 
> have this scenario:
> 
> main_project.pro <- [eeschema/libraries] .. list of libraries
> main_project_main_schematic.sch <- LIBS: ... list
> child_page.sch <- LIBS: ... list
> ..
> main_project-cache.lib <- cache files of libraries components
> main_project.net <- (libsource (lib LIB_NAME) (part C))
> 
> This is somewhat confusing! :) But as a user it is not a problem for me as it 
> works...
> 
> I will do the "workaround" reordering of my libraries.. not a problem for me 
> now that I know how it works..


I think the sort() call has to go, so I now think you discovered something.

Should have a fix in minutes.

When the foundations get simpler, so do the algorithms.


Dick



___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/18/2014 04:03 PM, Dick Hollenbeck wrote:
> On 08/18/2014 03:36 PM, Wayne Stambaugh wrote:
>> On 8/18/2014 4:30 PM, Mário Luzeiro wrote:
>>> I found that if I have multiple libraries with same component names 
>>> (notable ex: R, C, INDUCTOR .. ) I cannot select another component other 
>>> than the one already cached (?). I mean, if I select a R from another 
>>> library it will load the same R as already loaded in the schematic.
>>> I am not sure if it is the same as before, or if it is displaying the first 
>>> that found in the libraries.
>>> This should be a very recent issue, because I have old projects with 
>>> multiple libraries with repeated names with no problem.
>>>
>>> Application: kicad
>>> Version: (2014-08-18 BZR 5081)-product Debug build
>>> wxWidgets: Version 3.0.1 (debug,wchar_t,compiler with C++ ABI 1002,GCC 
>>> 4.8.2,wx containers,compatible with 2.8)
>>> Platform: Linux 3.13.0-32-generic x86_64, 64 bit, Little endian, wxGTK
>>> Boost version: 1.54.0
>>>  USE_WX_GRAPHICS_CONTEXT=OFF
>>>  USE_WX_OVERLAY=OFF
>>>  KICAD_SCRIPTING=OFF
>>>  KICAD_SCRIPTING_MODULES=OFF
>>>  KICAD_SCRIPTING_WXPYTHON=OFF
>>>  USE_FP_LIB_TABLE=HARD_CODED_ON
>>>  BUILD_GITHUB_PLUGIN=ON
>>>
>>> Mario Luzeiro
>>
>> I just got bit by this too.  I'm using r5081 as well so it must have
>> changed in one of the last few commits.


Wayne,

Take a look at PART_LIBS::LoadAllLibraries().

The only thing that changed that I am aware of is that the LibNames no longer 
may take
paths in the dialog UI.  That was too much of a circus in my view, so I nuked 
that concept
in the UI.  You now get a list of libraries and paths on where to find them.

The other thing that might be the cause of a problem is the sortOrder, although 
I thought
I had removed the need for that.  It clearly is not being set.

Try the attached patch please.

I still don't get the need for the sortOrder even if this is a fix.  I think we 
can remove
it, and I'd like to because it is a global.


Dick



=== modified file 'eeschema/class_library.cpp'
--- eeschema/class_library.cpp	2014-08-13 20:28:54 +
+++ eeschema/class_library.cpp	2014-08-18 21:16:09 +
@@ -1057,7 +1057,6 @@
 wxFileName  fn;
 wxStringfilename;
 wxStringlibs_not_found;
-wxArrayString   sortOrder;
 SEARCH_STACK*   lib_search = aProject->SchSearchS();
 
 #if defined(DEBUG) && 1
@@ -1147,6 +1146,9 @@
 UTF8( libs_not_found ), 0, 0 );
 }
 
+wxArrayString   sortOrder = lib_names;
+sortOrder.Add( cache_name );
+
 // Put the libraries in the correct order.
 PART_LIBS::SetSortOrder( sortOrder );
 

___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/18/2014 03:36 PM, Wayne Stambaugh wrote:
> On 8/18/2014 4:30 PM, Mário Luzeiro wrote:
>> I found that if I have multiple libraries with same component names (notable 
>> ex: R, C, INDUCTOR .. ) I cannot select another component other than the one 
>> already cached (?). I mean, if I select a R from another library it will 
>> load the same R as already loaded in the schematic.
>> I am not sure if it is the same as before, or if it is displaying the first 
>> that found in the libraries.
>> This should be a very recent issue, because I have old projects with 
>> multiple libraries with repeated names with no problem.
>>
>> Application: kicad
>> Version: (2014-08-18 BZR 5081)-product Debug build
>> wxWidgets: Version 3.0.1 (debug,wchar_t,compiler with C++ ABI 1002,GCC 
>> 4.8.2,wx containers,compatible with 2.8)
>> Platform: Linux 3.13.0-32-generic x86_64, 64 bit, Little endian, wxGTK
>> Boost version: 1.54.0
>>  USE_WX_GRAPHICS_CONTEXT=OFF
>>  USE_WX_OVERLAY=OFF
>>  KICAD_SCRIPTING=OFF
>>  KICAD_SCRIPTING_MODULES=OFF
>>  KICAD_SCRIPTING_WXPYTHON=OFF
>>  USE_FP_LIB_TABLE=HARD_CODED_ON
>>  BUILD_GITHUB_PLUGIN=ON
>>
>> Mario Luzeiro
> 
> I just got bit by this too.  I'm using r5081 as well so it must have
> changed in one of the last few commits.


Never in the history of eeschema did you have a choice between multiple 
lib_parts
identically named "R".  The library listing order always determined which one 
you got.

You always had to have uniquely name lib_parts, or settle for whatever the 
search order
gave you.

Just run the dialog and fix your library order.

Dick


___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

The order of parts search is given by the order of library names in the *.pro 
file.
Here in my project, you see the first two are mine, followed by the standard 
ones.

One is project specific and the other is cross project:
If you change this order, by dialog or text editor, you will get different 
results.

I have an "R" symbol in mylib.But when I pick a lib_part, the UI points me 
to the
first "R" it finds according to an alphabetical listing of the libraries, not 
one
according to this search oder.  No matter, I ultimately get the right one, from 
mylib.

We should probably not do the lib_part picking using alphabetical libraries?


LibName1=project
LibName2=mylib
LibName3=power
LibName4=device
LibName5=transistors
LibName6=conn
LibName7=linear
LibName8=regul
LibName9=74xx
LibName10=cmos4000
LibName11=adc-dac
LibName12=memory
LibName13=xilinx
LibName14=special
LibName15=microcontrollers
LibName16=dsp
LibName17=microchip
LibName18=analog_switches
LibName19=motorola
LibName20=texas
LibName21=intel
LibName22=audio
LibName23=interface
LibName24=digital-audio
LibName25=philips
LibName26=display
LibName27=cypress
LibName28=siliconi
LibName29=opto
LibName30=atmel
LibName31=contrib



___
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] Eeschema issue: cannot load component from multi libraries with same component name

[Dick Hollenbeck]

On 08/18/2014 03:30 PM, Mário Luzeiro wrote:
> I found that if I have multiple libraries with same component names (notable 
> ex: R, C, INDUCTOR .. ) I cannot select another component other than the one 
> already cached (?). I mean, if I select a R from another library it will load 
> the same R as already loaded in the schematic.
> I am not sure if it is the same as before, or if it is displaying the first 
> that found in the libraries.


1) This is not new.

No, this is prior behaviour, nothing recent.

The component actually used will depend on the search path sequence.  that 
sequence is
totally given in .pro although not explicitly.  If you want to know 
the algorithm
for extracting information from there, look at

  PART_LIBS::LibNamesAndPaths()

This is an aggregation of shit that was spread all over the map before.  At 
least you can
now see it for what it is.


2) You cannot *actually* choose between various "R" library parts.  You will 
ultimately
get the one decided by 1) above.  Although


3) There has bee a bug in the library part chooser for some time in that it 
seems not to
known anything about the reality of 1)

-

The reality of 1) is why Wayne and I spent a year ripping it out of Pcbnew.  It 
is not a
pretty reality, I hated it intensely and we replaced it with the fp-lib-table 
concepts.





> This should be a very recent issue, because I have old projects with multiple 
> libraries with repeated names with no problem.

Nonsense.  You got what the library search path gave you.  You can change that 
sequence
and get a different one (possibly for all parts in that same library).



> 
> Application: kicad
> Version: (2014-08-18 BZR 5081)-product Debug build
> wxWidgets: Version 3.0.1 (debug,wchar_t,compiler with C++ ABI 1002,GCC 
> 4.8.2,wx containers,compatible with 2.8)
> Platform: Linux 3.13.0-32-generic x86_64, 64 bit, Little endian, wxGTK
> Boost version: 1.54.0
>  USE_WX_GRAPHICS_CONTEXT=OFF
>  USE_WX_OVERLAY=OFF
>  KICAD_SCRIPTING=OFF
>  KICAD_SCRIPTING_MODULES=OFF
>  KICAD_SCRIPTING_WXPYTHON=OFF
>  USE_FP_LIB_TABLE=HARD_CODED_ON
>  BUILD_GITHUB_PLUGIN=ON
> 
> Mario Luzeiro
> ___
> 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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/18/2014 05:37 AM, Nick Østergaard wrote:
> Hello Dick
> 
> I see a bug in your commit 5072 (also present in latest commit 5079).
> In that commit; when opening a schematic, then all connections are
> showed as not connected (with the square green box around the end
> nodes). When drawing a new wire they all look connected again. See the
> attached image for how it look.
> 
> Not knowing the internals of this, it seems that a calculation of this
> is not made when opening the sheet.
> 
> Regards
> Nick Østergaard


Jean-Pierre graciously agreed to look into this.  I'm only fixing bugs that 
bother me
personally a lot this week.  I need to get other work done.


Dick


___
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] eeschema modular kicad work

[Dick Hollenbeck]

>>
> Good news !
> 
> thanks Dick !
> 
> but where is that 5089 version ? I just ran the install script and it 
> updated to 5081. May be it was 5079 ?

Yes.


___
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] eeschema modular kicad work

[Dick Hollenbeck]

>> Patch solved the issue, seemed to work like a charm... But induced another 
>> issue. Step to
>> reproduce :
>>
>> 1 - open kicad, then open eeschema and pcbnew
>> 2 - in pcbnew, open the module properties dialog on any part you want.
>> 3 - go back to eeschema, wich is now responding normally, and open  the 
>> component
>> properties dialog, on the same part or another one (doesn't matters).
>> 4 - go back to pcbnew, close the dialog, either with OK or Cancel --> dialog 
>> closes, but
>> pcbnew is frozen and also can't be closed in any normal way.
>> eeschema still works, you can close the dialog and use it normally. Kicad 
>> main window
>> works also.
>> Eeschema can be closed normally, kicad main window also, but when closing 
>> main window,
>> pcbnew window closes too, but the kicad process is still there and you need 
>> to kill it.
>>
>> I thought I will modify eeschema in the same way to test if it does 
>> something else, and so
>> I noticed the eeschema component properties dialog was alredy a QuasiModal 
>> one.
>>
>> And obviously the same test starting with eeschema instead of pcbnew leads 
>> to to opposite
>> result : eeschema stuck, pcbnew working.
>> And again, the need to kill kicad process after closing the main window.
> 
> 
> Excellent job testing, yann.
> 
> This will take some time to look into and I started last night.
> 
> Achieving platform independent and wx version independent results looks very 
> difficult at
> this point.
> 


Yann,

This is now fixed to the best degree I know how in 5089.  But you need to use 
wx3.x for it
to work.

It it not perfect, but quasimodal is a graft on top of the wx API, and without 
going to
the platform API for further experimentation, we're limited.  Still way ahead 
of where we
started I would say.

It's good enough for me, anyways.

Dick


___
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] KiCad build.

[Dick Hollenbeck]

On 08/16/2014 11:44 AM, Wayne Stambaugh wrote:
> One of the tasks that I have committed to working on in the KiCad road
> map is to clean up the current mess we have created by allowing
> dependency libraries to be built as part of the KiCad source build.  The
> only exception I see for the time being is Boost.  Although I am have my
> reservations on that as well.  Why you ask?  I've spent several days
> trying to get KiCad to build on Windows using MSYS2 as my build
> environment and mingw64 as my target environment.  Every single library
> dependency with the exception of our custom Boost and avhttp (which
> could easily be build and installed using CMake) are already packaged
> for me.  However, the current KiCad build insists on downloading and
> building some libraries from source that are already installed.  This is
> silly.  I can resolve the issues by passing all of the
> PACKAGE_ROOT_PATHs when I run CMake but that is silly as well since my
> build environment already points the correct path.
> 
> Originally I intended to create a separate project to build the KiCad
> library dependencies but I have since changed my mind.  I do *not* think
> it is asking too much of developers to learn how to build and/or install
> libraries on their preferred platform.  If as a developer you must have
> this done for you automatically, I am going to please ask that *you*
> create a separate platform specific build tool such as the excellent
> kicad-winbuilder that Brian has created.  This will significantly
> simplify the KiCad CMake files and eliminate the situation I described
> above.  My preference and goal is that the KiCad CMake files be used to
> build KiCad, not library dependencies.
> 
> Initially, I plan to remove the dependencies that do not require any
> patching to build which currently are avhttp, swig, cairo, libpng,
> pixman, pcre, pkgconfig, and glew.  Then I will remove the dependencies
> with platform specific patches which are openssl, wxwidgets and
> wxpython.  Then I will try to figure out what to do with the problem
> child that is Boost.  I would also suggest that all platform specific
> library dependency build patches be remove as well leaving only the
> Boost patches that are required for all platforms (except the context
> switching patches).
> 
> My goal here is not to step on anyone's toes it is to get our build
> system under control so that I can build *KiCad* rather than figure out
> how to get the dependencies to build or not as the platform dictates.  I
> expect our code to be well designed and I don't think expecting the same
> from our build system design is out of line. 


> If any one has major
> objections then we will have to figure something out because I am not
> going to continue to spend valuable time fighting our build tools to get
> them to properly use the dependencies already installed on my platform.
> 
> Wayne


I empathize with you.  I say you simply put your foot down.  This is one of 
those "Linus
sends the ARM maintainers back to the drawing board with device tree" moments.  
Except
that CMake is better than device tree.  Here the Mac and windows builders have 
to pay.


My suggestions:

Really you Wayne could just delete stuff you don't want in there.  Then do a 
diff.  Take
the negative of the diff and make that a second CMake "kicad prerequisites" 
builder.So
it gets split into two builders, and initially the second half will not work, 
but the Mac
and Windows guys can clean it up.

After all from your perspective you are not breaking anything, you are 
restoring order to
a build system you've used for years without issue until recently.

But caution.  CMake is an awesome builder.  One should not assume that anything 
in there
is expendable.  Its all very valuable information, it just needs to be 
separated out.  I
would also say that this is NOT a platform specific discussion.

If someone wants to build a windows KiCad on linux, then they certainly have 
few to no
previously installed packages and the knowledge embodied in these recipes is 
critical (and
cross-platform/cross-compiling with minor work).

Each external_project in the second build system could be Yes/No selectable.  
It is a real
opportunity for a someone to develop a valuable tool that would extend beyond 
KiCad.  And
maybe some of the folks that put together CMake would be willing to offer help 
and advice.
 There are some advanced ways for information to flow from the first pass 
builder into the
kicad builder.

This is an opportunity for many and for much.   It is also potentially a junk 
yard, unless
enough step up to pick up the pieces.  I won't be able to help, but I see much 
promise in
this.

Certainly the MAC developers have the most to lose here, and with a little help 
can keep
this from becoming a catastrophic blow to the KiCad Mac support.  While at the 
same time
bringing value to the Mac and Windows platforms for a broad range of other 
projects.


Dick






___

Re: [Kicad-developers] Segfault when running DRC

[Dick Hollenbeck]

On 08/15/2014 11:04 PM, Andrew Zonenberg wrote:
> I filed a ticket with upstream
> http://trac.wxwidgets.org/ticket/16423#ticket so we'll see what they
> say.
> 
> On Fri, 2014-08-15 at 23:53 -0400, Andrew Zonenberg wrote:
>> The invalid read seems to be a bug in wxWidgets:
>>
>> src/gtk/window.cpp:1543
>>
>> static void SendSetCursorEvent(wxWindowGTK* win, int x, int y)
>> {
>> wxSetCursorEvent event(x, y);
>> wxWindowGTK* w = win;
>> do {
>> if (w->GTKProcessEvent(event))
>> {
>> gs_overrideCursor = &event.GetCursor();

That's a good catch.  3.0.1 has this bug.  3.0.0 does not.

And SVN HEAD does not.  Sheesh.

Here's subversion head as of today:

static void SendSetCursorEvent(wxWindowGTK* win, int x, int y)
{
wxSetCursorEvent event(x, y);
wxWindowGTK* w = win;
do {
if (w->GTKProcessEvent(event))
{
win->GTKUpdateCursor(false, false, &event.GetCursor());
win->m_needCursorReset = true;
return;
}
// this is how wxMSW works...
if (w->GetCursor().IsOk())
break;
w = w->GetParent();
} while (w);
if (win->m_needCursorReset)
win->GTKUpdateCursor();
}


For a long while I was simply using SVN head and updating it every couple of 
months.  It
does seem better than 3.0.1 at least in this regard.

It is a shame that this blows the confidence in 3.0.1.  Although if a person 
was going to
build from source, I suppose they could patch this bug before building.


Anyways, nothing wrong with compatibility of that package you installed, it 
simply has a
crashing bug in it.


Dick




>> win->GTKUpdateCursor();
>> gs_needCursorResetMap[win] = true;
>> return;
>> }
>> // this is how wxMSW works...
>> if (w->GetCursor().IsOk())
>> break;
>> w = w->GetParent();
>> } while (w);
>> if (gs_needCursorResetMap[win])
>> win->GTKUpdateCursor();
>> }
>>
>> event is a local variable on the stack and as a result, as soon as this
>> function returns gs_overrideCursor is invalid.
>>
>> I'm not yet sure if this has any relationship whatsoever to the crash
>> I'm hunting.
>>
>> On Fri, 2014-08-15 at 23:31 -0400, Andrew Zonenberg wrote:
>>> I'm not using codelight itself, just their precompiled wx binaries, so I
>>> can easily remove the binary package, it was just less work than
>>> compiling from source.
>>>
>>> I'm investigating further now, I fixed an unrelated missing variable
>>> initializer in the process and will be submitting a patch to that
>>> shortly.
>>>
>>> On Fri, 2014-08-15 at 22:14 -0500, Dick Hollenbeck wrote:
>>>> On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
>>>>> Does not crash when run under Valgrind, instead gives this error:
>>>>>
>>>>> ==32723== Invalid read of size 8
>>>>
>>>> ^ this error?  I've seen that before and never could figure it out, nor 
>>>> was it ever the
>>>> cause of any problem running valgrind.
>>>>
>>>> I would say build your own wxwidgets from the 3.0.1 source.  We're dealing 
>>>> with an unknown
>>>> problem, so one has to revert to probabilities at that point.
>>>>
>>>> I think the highest probability is that there is some incompatibility in 
>>>> your software
>>>> stack.  Building wx from source is an easy experiment.  You do not have to 
>>>> remove the wx
>>>> package if it makes codelight happy.
>>>>
>>>> Follow the instructions I gave in an earlier email today.  Then after 
>>>> configuring the
>>>> kicad build, I run
>>>>
>>>> (ccmake is in the package cmake-curses-gui I think.)
>>>>
>>>> $ ccmake .
>>>>
>>>> in the build directory.  Then I paste in
>>>>
>>>>   /opt/wx3.0-stl/bin/wx-config
>>>>
>>>> into the field named:  wxWidgets_CONFIG_EXECUTABLE and reconfigure in 
>>>> ccmake.
>>>>
>>>> Likewise for the debug build, which over time will be very helpful for you.
>>>>
>>>>
>>>> Obviously the first part of the /opt/wx3.0-stl/bin/wx-config string came 
>>>> from the --prefix
>>>> argument to the wx configure command.
>>>>
>>>> Don'

Re: [Kicad-developers] Segfault when running DRC

[Dick Hollenbeck]

On 08/15/2014 08:32 PM, Andrew Zonenberg wrote:
> Does not crash when run under Valgrind, instead gives this error:
> 
> ==32723== Invalid read of size 8

^ this error?  I've seen that before and never could figure it out, nor was it 
ever the
cause of any problem running valgrind.

I would say build your own wxwidgets from the 3.0.1 source.  We're dealing with 
an unknown
problem, so one has to revert to probabilities at that point.

I think the highest probability is that there is some incompatibility in your 
software
stack.  Building wx from source is an easy experiment.  You do not have to 
remove the wx
package if it makes codelight happy.

Follow the instructions I gave in an earlier email today.  Then after 
configuring the
kicad build, I run

(ccmake is in the package cmake-curses-gui I think.)

$ ccmake .

in the build directory.  Then I paste in

  /opt/wx3.0-stl/bin/wx-config

into the field named:  wxWidgets_CONFIG_EXECUTABLE and reconfigure in ccmake.

Likewise for the debug build, which over time will be very helpful for you.


Obviously the first part of the /opt/wx3.0-stl/bin/wx-config string came from 
the --prefix
argument to the wx configure command.

Don't forget to run $ sudo ldconfig
after installing the home made wx libraries.





> ==32723==at 0x5D00EC0: wxCursor::GetCursor() const (cursor.cpp:287)
> ==32723==by 0x5D20A8D: wxWindow::GTKUpdateCursor(bool, bool)
> (window.cpp:3752)
> ==32723==by 0x5D002A0: UpdateCursors(wxWindow*, bool)
> (cursor.cpp:331)
> ==32723==by 0x5D00F42: SetGlobalCursor(wxCursor const&)
> (cursor.cpp:350)
> ==32723==by 0x5D0109C: wxEndBusyCursor() (cursor.cpp:376)
> ==32723==by 0x1D3FCCDB:
> DIALOG_DRC_CONTROL::OnStartdrcClick(wxCommandEvent&)
> (dialog_drc.cpp:172)
> ==32723==by 0x65F92DE:
> wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&,
> wxEvent&) const (appbase.cpp:623)
> ==32723==by 0x6750FF1:
> wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&,
> wxEvtHandler*, wxEvent&) (event.cpp:1384)
> ==32723==by 0x67513A5:
> wxEvtHandler::SearchDynamicEventTable(wxEvent&) (event.cpp:1743)
> ==32723==by 0x6751445: wxEvtHandler::TryHereOnly(wxEvent&)
> (event.cpp:1577)
> ==32723==by 0x6751502: wxEvtHandler::ProcessEventLocally(wxEvent&)
> (event.h:3671)
> ==32723==by 0x6751564: wxEvtHandler::ProcessEvent(wxEvent&)
> (event.cpp:1487)
> ==32723==  Address 0x7feffdee8 is not stack'd, malloc'd or (recently)
> free'd
> 
> 
> On Fri, 2014-08-15 at 21:19 -0400, Andrew Zonenberg wrote:
>> Happens every time I run DRC on this board. I don't want to change the
>> design for fear of not being able to reproduce it.
>>
>> This is with the Codelite packages of wx3.0.1 and BZR 5073 kicad on
>> Debian 7.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
>> at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
>> 57   /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c: No such file or
>> directory.
>> (gdb) bt
>> #0  IA__gdk_cursor_ref (cursor=cursor@entry=0xf2e66c318c48348)
>> at /tmp/buildd/gtk+2.0-2.24.10/gdk/gdkcursor.c:57
>> #1  0x747cc691 in IA__gdk_window_set_cursor (window=0xbe3120,
>> cursor=0xf2e66c318c48348) at /tmp/buildd/gtk
>> +2.0-2.24.10/gdk/gdkwindow.c:8199
>> #2  0x76b8897f in wxWindow::GTKUpdateCursor (this=0x8273f0,
>> isBusyOrGlobalCursor=, isRealize=false)
>> at ../src/gtk/window.cpp:3761
>> #3  0x76b682a1 in UpdateCursors (win=win@entry=0x8273f0,
>> isBusyOrGlobalCursor=) at ../src/gtk/cursor.cpp:331
>> #4  0x76b68f43 in SetGlobalCursor (cursor=...)
>> at ../src/gtk/cursor.cpp:350
>> #5  0x76b6909d in wxEndBusyCursor ()
>> at ../src/gtk/cursor.cpp:376
>> #6  0x7fffe26f4cdc in DIALOG_DRC_CONTROL::OnStartdrcClick
>> (this=0x3645700, event=...)
>> at 
>> /nfs/home/azonenberg/Documents/local/programming/3rdparty/kicad/pcbnew/dialogs/dialog_drc.cpp:172
>> #7  0x7627c2df in wxAppConsoleBase::CallEventHandler
>> (this=0x7b29e0, handler=0x3645700, functor=..., event=...)
>> at ../src/common/appbase.cpp:623
>>
>>
>> ___
>> 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] Bug 593782 fixed already, but other problem noticed

[Dick Hollenbeck]

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


___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
> As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
> kicad continues to build on it until the next stable Debian version
> (presumably shipping wx 3.0) is released.

You have that capability.  Probably I will uninstall wx2.8 tomorrow.

There would be no reason to reject your patches on this topic, and you could 
easily make a
lot of people happy.

But don't think I was bullshitting you when I said I would not spend another 
minute on it.



> If new features can't be easily made to work on wx2.8 that's
> understandable as long as there's some graceful downgrade in
> functionality rather than a total build failure.
> 
>> My motive to support wx2.8 is now zilch.  The project can make its own 
>> policy without my
>> input on wx2.8 support, but I personally won't spend another minute on it.
>>
>> Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.
>>
>>
>> Dick




___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/15/2014 02:16 PM, Wayne Stambaugh wrote:
> On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
>> On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
>>> On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
>>>> On 08/14/2014 07:31 PM, yann jautard wrote:
>>>>>
>>>>> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>>>>>>> I don't know if it is technically possible to change this behaviour, 
>>>>>>> but 
>>>>>>> I think it could be a great improvement.
>>>>>>>
>>>>>> :
>>>>>>> yann
>>>>>>>
>>>>>> Hopefully QuasiModal is not a monster.
>>>>>>
>>>>>> For significant dialogs (ones which tend to be open for a while) using 
>>>>>> the QuasiModal
>>>>>> support in DIALOG_SHIM might be a solution to this.  It disables the 
>>>>>> window which invokes
>>>>>> the dialog, but nothing more.
>>>>>>
>>>>>> Without the QuasiModal support, the behaviour is platform specific.  On 
>>>>>> linux, I *CAN*
>>>>>> open the schematic editor while viewing footprint properties and scroll, 
>>>>>> but I cannot
>>>>>> close the schematic window.  So that behaviour is arguably worse, since 
>>>>>> it looks like a
>>>>>> bug.  (It is not a bug that I would respond to.  Let's register it as 
>>>>>> folklore.)
>>>>>
>>>>> Hi Dick,
>>>>>
>>>>> This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
>>>>> window frozen when
>>>>> dialog opened in pcbnew.
>>>>>
>>>>>>
>>>>>> Remember if you cannot close a major KIWAY_PLAYER using system window 
>>>>>> decorations, this
>>>>>> might be because you have a dialog window opened elsewhere on linux.
>>>>>>
>>>>>> Please see if this patch fixes the sample issue for you.  The QuasiModal 
>>>>>> support was
>>>>>> something I came up with using only the wxWindows API, not a platform 
>>>>>> specific approach.
>>>>>> I don't know that its been tested enough across all platforms.  Bad news 
>>>>>> is that there may
>>>>>> not be anything I can do except for Linux to fix it, should it not work 
>>>>>> wonderfully on all
>>>>>> platforms.
>>>>>
>>>>>
>>>>>
>>>>> Patch solved the issue, seemed to work like a charm... But induced 
>>>>> another issue. Step to
>>>>> reproduce :
>>>>>
>>>>> 1 - open kicad, then open eeschema and pcbnew
>>>>> 2 - in pcbnew, open the module properties dialog on any part you want.
>>>>> 3 - go back to eeschema, wich is now responding normally, and open  the 
>>>>> component
>>>>> properties dialog, on the same part or another one (doesn't matters).
>>>>> 4 - go back to pcbnew, close the dialog, either with OK or Cancel --> 
>>>>> dialog closes, but
>>>>> pcbnew is frozen and also can't be closed in any normal way.
>>>>> eeschema still works, you can close the dialog and use it normally. Kicad 
>>>>> main window
>>>>> works also.
>>>>> Eeschema can be closed normally, kicad main window also, but when closing 
>>>>> main window,
>>>>> pcbnew window closes too, but the kicad process is still there and you 
>>>>> need to kill it.
>>>>>
>>>>> I thought I will modify eeschema in the same way to test if it does 
>>>>> something else, and so
>>>>> I noticed the eeschema component properties dialog was alredy a 
>>>>> QuasiModal one.
>>>>>
>>>>> And obviously the same test starting with eeschema instead of pcbnew 
>>>>> leads to to opposite
>>>>> result : eeschema stuck, pcbnew working.
>>>>> And again, the need to kill kicad process after closing the main window.
>>>>
>>>>
>>>> Excellent job testing, yann.
>>>>
>>>> This will take some time to look into and I started last night.
>>>>
>>>> Achieving platform independent and wx version independent results lo

Re: [Kicad-developers] eeschema modular kicad work

[Dick Hollenbeck]

On 08/15/2014 10:26 AM, Барановский Константин wrote:
> I'm catched the bug where the window of the eeschema freezes.
> 
> To reproduce do the next:
> 1) start kicad and opens some project (with existing schematic);
> 2) from kicad's panel start eeschema;
> 3) for some component in context menu (right click) select "Edit 
> component -> Edit";
> After this step opens dialog window for edititg the component's props.
> 4) close dialog by close button (x-like button on top of the window);
> 5) dialog closes and eeschema frizz.
> But if close dialog by Cancel button at the button - all works.
> 
> Application: kicad
> Version: (2014-08-14 BZR 5074)-product Release build
> wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 
> 1002,GCC 4.8.2,wx containers,compatible with 2.6)
> Platform: Linux 3.13.0-33-generic i686, 32 bit, Little endian, wxGTK
> Boost version: 1.54.0
>   USE_WX_GRAPHICS_CONTEXT=OFF
>   USE_WX_OVERLAY=OFF
>   KICAD_SCRIPTING=ON
>   KICAD_SCRIPTING_MODULES=ON
>   KICAD_SCRIPTING_WXPYTHON=ON
>   USE_FP_LIB_TABLE=HARD_CODED_ON
>   BUILD_GITHUB_PLUGIN=ON
> 



I don't see this bug when I use:  A) new code from last night + B) wx3.x.  I 
see bug with
wx2.8.


I don't know for sure whether using wx3.x alone will fix this, but you could 
try.  If not
rest assured a fix is in hand, but one that depends on wx3.x.

The wx2.8 solution will be to switch back to modal for this particular dialog 
as part of a
macro that can be re-purposed.  Using the modal form of the macro on this 
dialog will also
fix the problem under wx2.8.


In your shoes, I'd start by installing wx3.x.  By either building it yourself, 
or finding
a package.  Here is how I build it:


$ ../configure --with-gtk --prefix=/opt/wx3.x-stl-release --with-expat 
--enable-html
--enable-stl --with-regex=builtin

and for a debug build:




From an out of tree build dir.

$ make -j4

$ make install

$ ldconfig


And for a debug build, run it a second time in a new out of tree build dir:

 $ ../configure --with-gtk --prefix=/opt/wx3.x-stl --enable-debug 
--enable-debug_info
--enable-debug_gdb --with-expat --enable-html --enable-stl --with-regex=builtin

$ make -j4

$ make install

$ ldconfig


It takes less than 10 minutes.

Dick



___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
> On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
>> On 08/14/2014 07:31 PM, yann jautard wrote:
>>>
>>> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>>>>> I don't know if it is technically possible to change this behaviour, but 
>>>>> I think it could be a great improvement.
>>>>>
>>>> :
>>>>> yann
>>>>>
>>>> Hopefully QuasiModal is not a monster.
>>>>
>>>> For significant dialogs (ones which tend to be open for a while) using the 
>>>> QuasiModal
>>>> support in DIALOG_SHIM might be a solution to this.  It disables the 
>>>> window which invokes
>>>> the dialog, but nothing more.
>>>>
>>>> Without the QuasiModal support, the behaviour is platform specific.  On 
>>>> linux, I *CAN*
>>>> open the schematic editor while viewing footprint properties and scroll, 
>>>> but I cannot
>>>> close the schematic window.  So that behaviour is arguably worse, since it 
>>>> looks like a
>>>> bug.  (It is not a bug that I would respond to.  Let's register it as 
>>>> folklore.)
>>>
>>> Hi Dick,
>>>
>>> This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
>>> window frozen when
>>> dialog opened in pcbnew.
>>>
>>>>
>>>> Remember if you cannot close a major KIWAY_PLAYER using system window 
>>>> decorations, this
>>>> might be because you have a dialog window opened elsewhere on linux.
>>>>
>>>> Please see if this patch fixes the sample issue for you.  The QuasiModal 
>>>> support was
>>>> something I came up with using only the wxWindows API, not a platform 
>>>> specific approach.
>>>> I don't know that its been tested enough across all platforms.  Bad news 
>>>> is that there may
>>>> not be anything I can do except for Linux to fix it, should it not work 
>>>> wonderfully on all
>>>> platforms.
>>>
>>>
>>>
>>> Patch solved the issue, seemed to work like a charm... But induced another 
>>> issue. Step to
>>> reproduce :
>>>
>>> 1 - open kicad, then open eeschema and pcbnew
>>> 2 - in pcbnew, open the module properties dialog on any part you want.
>>> 3 - go back to eeschema, wich is now responding normally, and open  the 
>>> component
>>> properties dialog, on the same part or another one (doesn't matters).
>>> 4 - go back to pcbnew, close the dialog, either with OK or Cancel --> 
>>> dialog closes, but
>>> pcbnew is frozen and also can't be closed in any normal way.
>>> eeschema still works, you can close the dialog and use it normally. Kicad 
>>> main window
>>> works also.
>>> Eeschema can be closed normally, kicad main window also, but when closing 
>>> main window,
>>> pcbnew window closes too, but the kicad process is still there and you need 
>>> to kill it.
>>>
>>> I thought I will modify eeschema in the same way to test if it does 
>>> something else, and so
>>> I noticed the eeschema component properties dialog was alredy a QuasiModal 
>>> one.
>>>
>>> And obviously the same test starting with eeschema instead of pcbnew leads 
>>> to to opposite
>>> result : eeschema stuck, pcbnew working.
>>> And again, the need to kill kicad process after closing the main window.
>>
>>
>> Excellent job testing, yann.
>>
>> This will take some time to look into and I started last night.
>>
>> Achieving platform independent and wx version independent results looks very 
>> difficult at
>> this point.
> 
> There may be no way to completely fix this without coming up with a
> really clever way of processing events between the dialog and the frame
> that launched the dialog.  Modal dialogs in wxWidgets by design steal
> the event queue from the current process.  Now that all of the top level
> frames run in the same process, every open frame will be blocked any
> time a modal dialog is run.  If you have Pcbnew and Eeschema open at the
> same time, a modal dialog opened in Eeschema will prevent the Pcbnew
> frame from receiving events and vice versa until the dialog is closed.
> Modeless dialogs would be one possible solution except for one glaring
> problem.  AFAIK every dialog (except the Eeshchema find dialog) in KiCad
> d

[Kicad-developers] wxwidgets 3.0 hits the Ubuntu repos

[Dick Hollenbeck]

http://packages.ubuntu.com/trusty/libwxgtk3.0-0

for Trusty only.

With "dev" packages too.


___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/14/2014 07:31 PM, yann jautard wrote:
> 
> Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
>>> I don't know if it is technically possible to change this behaviour, but 
>>> I think it could be a great improvement.
>>>
>> :
>>> yann
>>>
>> Hopefully QuasiModal is not a monster.
>>
>> For significant dialogs (ones which tend to be open for a while) using the 
>> QuasiModal
>> support in DIALOG_SHIM might be a solution to this.  It disables the window 
>> which invokes
>> the dialog, but nothing more.
>>
>> Without the QuasiModal support, the behaviour is platform specific.  On 
>> linux, I *CAN*
>> open the schematic editor while viewing footprint properties and scroll, but 
>> I cannot
>> close the schematic window.  So that behaviour is arguably worse, since it 
>> looks like a
>> bug.  (It is not a bug that I would respond to.  Let's register it as 
>> folklore.)
> 
> Hi Dick,
> 
> This sounds pretty strange : I'm on linux too, and I can't. Kicad main window 
> frozen when
> dialog opened in pcbnew.
> 
>>
>> Remember if you cannot close a major KIWAY_PLAYER using system window 
>> decorations, this
>> might be because you have a dialog window opened elsewhere on linux.
>>
>> Please see if this patch fixes the sample issue for you.  The QuasiModal 
>> support was
>> something I came up with using only the wxWindows API, not a platform 
>> specific approach.
>> I don't know that its been tested enough across all platforms.  Bad news is 
>> that there may
>> not be anything I can do except for Linux to fix it, should it not work 
>> wonderfully on all
>> platforms.
> 
> 
> 
> Patch solved the issue, seemed to work like a charm... But induced another 
> issue. Step to
> reproduce :
> 
> 1 - open kicad, then open eeschema and pcbnew
> 2 - in pcbnew, open the module properties dialog on any part you want.
> 3 - go back to eeschema, wich is now responding normally, and open  the 
> component
> properties dialog, on the same part or another one (doesn't matters).
> 4 - go back to pcbnew, close the dialog, either with OK or Cancel --> dialog 
> closes, but
> pcbnew is frozen and also can't be closed in any normal way.
> eeschema still works, you can close the dialog and use it normally. Kicad 
> main window
> works also.
> Eeschema can be closed normally, kicad main window also, but when closing 
> main window,
> pcbnew window closes too, but the kicad process is still there and you need 
> to kill it.
> 
> I thought I will modify eeschema in the same way to test if it does something 
> else, and so
> I noticed the eeschema component properties dialog was alredy a QuasiModal 
> one.
> 
> And obviously the same test starting with eeschema instead of pcbnew leads to 
> to opposite
> result : eeschema stuck, pcbnew working.
> And again, the need to kill kicad process after closing the main window.


Excellent job testing, yann.

This will take some time to look into and I started last night.

Achieving platform independent and wx version independent results looks very 
difficult at
this point.


___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/13/2014 06:40 PM, Wayne Stambaugh wrote:
> On 8/13/2014 6:23 PM, Dick Hollenbeck wrote:
>> On 08/13/2014 03:43 PM, Wayne Stambaugh wrote:
>>> On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:
>>>>
>>>> Many changes were introduced in revision 5072.
>>>>
>>>> If you are happy with your current binaries, stay where you are until the 
>>>> pond settles.
>>>>
>>>> If you want to see if your known bugs are fixed, then take a look at it 
>>>> and that testing
>>>> will be appreciated.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Dick
>>>>
>>>
>>> I did some preliminary testing over the weekend and didn't see any
>>> issues but my testing was limited to schematic editor.  I did not get a
>>> chance to test the part library editor or viewer.  I've seen that you've
>>> made a few changes since my initial testing so I don't if they effected
>>> the testing I did.  I try doing some more extensive testing over next
>>> few days with the latest and greatest code.  
>>
>> Thank you very much.
>>
>>> This was a lot of work.
>>
>>
>> Towards the end I was liking KiCad source code less and less.  This idea 
>> that you make a
>> screw driver with a hammer on the end of it was driving me nuts.  How about 
>> a screwdriver
>> separate from a hammer?
>>
>> Many many KiCad functions are simply too complicated, and needed to be split 
>> into 2,
>> sometimes 3 or more.
> 
> You would have had a stroke if you looked at it before all of my
> refactoring up work that I did during the first few years I was with the
> project.  Almost all of the work I did on Eeschema (except for the find
> dialog) was code refactoring and design simplification.  Even then, I
> knew there was still plenty left to clean up.  This is some of the most
> thankless work because the only people who really appreciate it are
> other developers who can appreciate quality software design. 


Thank you Wayne.

Your help during those early years were invaluable to the viability of the 
project.

Now, you'll need all the support you can find to continue and not get 
discouraged like me.


Regards,

Dick

"One man's trash is another man's treasure",
  a time travelling software engineer.






> I know it
> was difficult seeing the forest through the trees and underbrush that is
> the Eeschema code.
> 
>>
>>
>> There are still some that I cannot understand even after reading the 
>> function header
>> documentation.
>>
>> This is highlighting the difference between a software architect and a 
>> programmer.
>>
>> Simple functions crafted together to create a complex architecture that is 
>> easily
>> understood is far better than complex functions crafted together to create a 
>> simple
>> architecture which remains incomprehensible.
>>
>>
>> No way I go through that torture without ranting.  Good thing there was no 
>> audio recording
>> of it.
> 
> Trust me when I tell you that I had more than a few choice adjectives
> when I was doing my refactoring.
> 
>>
>> We're near the end now.
>>
>>
>>
>>> Thank you!
>>>
>>> Wayne
>>>


___
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] eeschema modular kicad work

[Dick Hollenbeck]

> I don't know if it is technically possible to change this behaviour, but 
> I think it could be a great improvement.
> 
:
> yann
>

Hopefully QuasiModal is not a monster.

For significant dialogs (ones which tend to be open for a while) using the 
QuasiModal
support in DIALOG_SHIM might be a solution to this.  It disables the window 
which invokes
the dialog, but nothing more.

Without the QuasiModal support, the behaviour is platform specific.  On linux, 
I *CAN*
open the schematic editor while viewing footprint properties and scroll, but I 
cannot
close the schematic window.  So that behaviour is arguably worse, since it 
looks like a
bug.  (It is not a bug that I would respond to.  Let's register it as folklore.)

Remember if you cannot close a major KIWAY_PLAYER using system window 
decorations, this
might be because you have a dialog window opened elsewhere on linux.

Please see if this patch fixes the sample issue for you.  The QuasiModal 
support was
something I came up with using only the wxWindows API, not a platform specific 
approach.
I don't know that its been tested enough across all platforms.  Bad news is 
that there may
not be anything I can do except for Linux to fix it, should it not work 
wonderfully on all
platforms.

If this patch works wonderfully, then someone wanting to contribute more of the 
same style
is welcome to.  Simply consider ShowModal() and EndModal() to be a matched set. 
 Replace
them with ShowQuasiModal() and EndQuasiModal() respectively.  Do not mix, keep 
the set
matched.

For me, not all dialogs are likely to be as *prominent* as others, i.e. their 
lifetimes.
In some cases we've used modeless dialogs.  That makes sense where we've used 
it, but it
requires an entirely different coding style from modal and quasimodal.  So 
injecting this
kind of quasimodal patch is easier than going full modal.

It might be prudent to introduce a couple of macros

#define ENDQUASIMODAL   EndQuasiModal
#define SHOWQUASIMODAL  ShowQuasiModal

So this can be turned off globally and revert to true modal if something bad 
gets
discovered down the line.  Then after enough testing we can do global search 
and replace
and jump off the macros.


Dick

=== modified file 'pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp'
--- pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp	2014-08-13 20:28:54 +
+++ pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp	2014-08-14 14:00:59 +
@@ -182,7 +182,7 @@
 
 void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent& event )
 {
-EndModal( -1 );
+EndQuasiModal( -1 );
 }
 
 
@@ -194,7 +194,7 @@
 m_Parent->OnModify();
 }
 
-EndModal( 2 );
+EndQuasiModal( 2 );
 }
 
 
@@ -204,7 +204,7 @@
 
 // Warning: m_CurrentModule was deleted by exchange module
 m_Parent->SetCurItem( NULL );
-EndModal( 0 );
+EndQuasiModal( 0 );
 }
 
 
@@ -675,7 +675,7 @@
 
 m_Parent->OnModify();
 
-EndModal( 1 );
+EndQuasiModal( 1 );
 
 if( m_DC )
 {

=== modified file 'pcbnew/editmod.cpp'
--- pcbnew/editmod.cpp	2014-05-18 15:16:59 +
+++ pcbnew/editmod.cpp	2014-08-14 13:59:27 +
@@ -59,12 +59,12 @@
 DIALOG_MODULE_BOARD_EDITOR* dialog = new DIALOG_MODULE_BOARD_EDITOR( this, Module, NULL );
 #endif
 
-int retvalue = dialog->ShowModal(); /* retvalue =
- *  -1 if abort,
- *  0 if exchange module,
- *  1 for normal edition
- *  and 2 for a goto editor command
- */
+int retvalue = dialog->ShowQuasiModal();/* retvalue =
+ *  -1 if abort,
+ *  0 if exchange module,
+ *  1 for normal edition
+ *  and 2 for a goto editor command
+ */
 dialog->Destroy();
 
 #ifdef __WXMAC__

___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 08/13/2014 03:43 PM, Wayne Stambaugh wrote:
> On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:
>>
>> Many changes were introduced in revision 5072.
>>
>> If you are happy with your current binaries, stay where you are until the 
>> pond settles.
>>
>> If you want to see if your known bugs are fixed, then take a look at it and 
>> that testing
>> will be appreciated.
>>
>>
>> Thanks,
>>
>> Dick
>>
> 
> I did some preliminary testing over the weekend and didn't see any
> issues but my testing was limited to schematic editor.  I did not get a
> chance to test the part library editor or viewer.  I've seen that you've
> made a few changes since my initial testing so I don't if they effected
> the testing I did.  I try doing some more extensive testing over next
> few days with the latest and greatest code.  

Thank you very much.

> This was a lot of work.


Towards the end I was liking KiCad source code less and less.  This idea that 
you make a
screw driver with a hammer on the end of it was driving me nuts.  How about a 
screwdriver
separate from a hammer?

Many many KiCad functions are simply too complicated, and needed to be split 
into 2,
sometimes 3 or more.


There are still some that I cannot understand even after reading the function 
header
documentation.

This is highlighting the difference between a software architect and a 
programmer.

Simple functions crafted together to create a complex architecture that is 
easily
understood is far better than complex functions crafted together to create a 
simple
architecture which remains incomprehensible.


No way I go through that torture without ranting.  Good thing there was no 
audio recording
of it.

We're near the end now.



> Thank you!
> 
> Wayne
> 
> 
> ___
> 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] eeschema modular kicad work

[Dick Hollenbeck]

Many changes were introduced in revision 5072.

If you are happy with your current binaries, stay where you are until the pond 
settles.

If you want to see if your known bugs are fixed, then take a look at it and 
that testing
will be appreciated.


Thanks,

Dick



___
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] CvPcb legacy configuration dialog.

[Dick Hollenbeck]

On 08/13/2014 10:34 AM, Wayne Stambaugh wrote:
> I just fixed the broken configuration toolbar button in CvPcb to launch
> the footprint library table editor.  I happened to notice that the
> legacy configuration dialog files are still in the dialog folder.  I
> think it's safe to remove them since we have been using the footprint
> library table for quite awhile now.  If there are no objections, I will
> remove them as part of my next commit.
> 
> Wayne


Not needed.



___
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] X2y Caps

[Dick Hollenbeck]

On 08/13/2014 10:31 AM, Jean-Paul Louis wrote:
> Hi Dick,
> Those app notes are interesting, but Johanson is known for high performance 
> aka very expensive devices.
> Is your design so critical that you have to worry about less than 0.5nH 
> inductance?
> Is it ultra high frequency? or very fast very high currents?
> 
> Just curious,
> Jean-Paul
> AC9GH


This is a reference design, distributed in our favourite format, self 
extracting exe file.

ftp://ftp.altera.com/outgoing/devkit/12.1/cycloneIVGX_4cgx150_fpga_v12.1.0.exe

In there is a *.pdf file showing the multi-port caps.  Altera seems to have a 
thing for them.

So does Freescale.  It seems to be a happening thing.

Yes, they are more expensive.  There are multiple suppliers, I assume this 
means multiple
patent licensees.  The BOM reduction comes about from needing less of them from 
what I can
see.


Dick



___
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] X2y Caps

[Dick Hollenbeck]

On 08/13/2014 10:07 AM, Wayne Stambaugh wrote:
> On 8/11/2014 10:24 PM, Dick Hollenbeck wrote:
>> We got any of these in our part or footprint libraries?
>>
>> http://www.johansondielectrics.com/technical-notes/x2y-application-notes/x2y-power-bypass-pcb-mounting.html#.U-l5WtZGlO4
>>
>>
> 
> I haven't seen any footprint like what is shown.  I've done similar
> footprints for handling multiple wire sizes although all of the
> connected pads are round and through hole so it should be doable
> although I've never tried mixing SMT and through hole pads to create a
> complex pad.  Thanks for the link.  There is a lot of good information
> there.  


> Although, I doubt I will ever have to worry about a couple of pF
> of bypass inductance in any of my designs.


Mr. Henry would be insulted.  :)


There were all kinds of papers on them in 2006.  It seems to be an example of 
the patent
system actually working like it was intended.  With the x2y caps, if they can 
claim lower
BOM cost, and higher performance, that is a win in my book.

An Altera reference design has them in there.  That means if I stray from their
recommendation, and the board does not work, I'm toast.

Seems I will need to make the parts and the footprints.  Veecandoodat.



___
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] wxString conversion issues in pcbnew/netlist.cpp [PATCH]

[Dick Hollenbeck]

/**
 * Function GetChars
 * returns a wxChar* to the actual wxChar* data within a wxString, and is
 * helpful for passing strings to wxString::Printf() and wxString::Format().
 * It can also be passed a UTF8 parameter which will be converted to wxString
 * by the compiler.
 * 
 * Example:  wxString::Format( wxT( "%s" ), GetChars( UTF( "some text" ) ) );
 * 
 * When wxWidgets is properly built for KiCad, a const wxChar* points to either:
 * 
 *  32 bit unicode characters on linux/OSX or 
 *  16 bit UTF16 characters on windows. 
 * 
 * Note that you cannot pass 8 bit strings to wxString::Format() or Printf() so 
this
 * is a useful conversion function to wxChar*, which is needed by 
wxString::Format().
 *
 * @return const wxChar* - a pointer to the UNICODE or UTF16 (on windows) text.
 */
static inline const wxChar* GetChars( const wxString& s )
{
#if wxCHECK_VERSION( 2, 9, 0 )
return (const wxChar*) s.c_str();
#else
return s.GetData();
#endif
}


___
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] wxString conversion issues in pcbnew/netlist.cpp [PATCH]

[Dick Hollenbeck]

On 08/13/2014 07:34 AM, Andrew Zonenberg wrote:


> wxString( fpOnBoard->GetFPID().GetFootprintName() ).GetData(),


I thought we could pass a UTF8 to GetChars() ?


GetChars( fpOnBoard->GetFPID().GetFootprintName() )


Seems simpler to read, the type promotion to wxString is then magical.





___
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] Fix for uninitialized variables and unchecked input buffers in eeschema [PATCH]

[Dick Hollenbeck]

committed in rev. 5065.

Thanks.

___
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] X2y Caps

[Dick Hollenbeck]

We got any of these in our part or footprint libraries?

http://www.johansondielectrics.com/technical-notes/x2y-application-notes/x2y-power-bypass-pcb-mounting.html#.U-l5WtZGlO4


___
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] Status of my merge request (parallelization of 3D model normal calculation using OpenMP)

[Dick Hollenbeck]

On 08/11/2014 07:51 PM, Andrew Zonenberg wrote:
> Hi all,
> 
> I submitted a merge request a week or two ago via Launchpad:
> https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+merge/229341
> 
> Orson and Wayne both commented on it with some minor concerns related to
> #ifdefs and code formatting. I pushed an updated version a few hours
> later addressing their concerns. Orson told me via IRC that he's fine
> with the updated code, and that's the last I've heard from anyone.
> 
> Are you guys just too busy to look at it right now? Did it get
> misplaced/forgotten? Are there any other issues with my code that
> nobody's told me about? It's not exactly urgent, but I'd like to get it
> merged eventually.
> 
> Thanks :)


Probably too busy.

line 41 of this:

https://code.launchpad.net/~azonenberg/kicad/advanced-feature-bugfixes/+merge/229341

is showing one indent level on a switch(), and this is incorrect.  Case 
statements are at
the same indent level as the switch().

 switch( m_CoordIndex[idx].size() )
40  {
41  case 3: glBegin( GL_TRIANGLES );break;
42  case 4: glBegin( GL_QUADS ); break;
43  default: glBegin( GL_POLYGON ); break;
44  }


Email formatting is not reliable here.

I am not taking any responsibility for committing it.   But this is one obvious 
deficiency.


You did good reminding those that have already commented.



___
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] doc repo is damaged

[Dick Hollenbeck]

This is why we can't have nice things.


Doing a checkout on the "docs" repo gives:


dick@dick-intel:/svn/kicad/product$ cd /tmp

dick@dick-intel:/tmp$ bzr co 
https://code.launchpad.net/~kicad-developers/kicad/doc


bzr: ERROR: No such file:
'http://bazaar.launchpad.net/~kicad-developers/kicad/doc/.bzr/repository/pack-names'



dick@dick-intel:/tmp$



Looks to me like the repo is damaged, probably because somebody did a "push" 
instead of a
"commit".   bzr is not git.


My copy of the docs repo is way old.

Ironically, pushing an older "good revision" is probably the fix.  Generally 
don't push
however!

Help from someone who does the docs regularly, please compare notes before you 
all decide
who has the latest good revision.




___
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] Contributing footprints

[Dick Hollenbeck]

On 08/04/2014 11:15 AM, Simon Gansen wrote:
> Hi,
> 
> I'm new to KiCad developement and wondering what is the designated way
> to contribute package footprints.
> 
> Once I've created a pull request at github for a schematic symbol to
> github.com/KiCad/kicad-library, which was merged a few hour later.
> 
> Now I've created a pull request to github.com/KiCad/SMD_Packages.pretty
> and there are neither comments nor a merge after 9 days. Is this github
> getting merged onto the bzr repository, or am I supposed to contribute
> using bzr? Or is there even an other way?


I just email the footprints to Carl, and be sure to say thank you.

He's made more progress in 5 months than the previous 5 years.



___
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] eeschema modular kicad work

[Dick Hollenbeck]

On 07/29/2014 02:02 PM, Wayne Stambaugh wrote:
> On 7/27/2014 1:33 PM, Dick Hollenbeck wrote:
>> Gentlemen:
>>
>> In the course of trying to load the schematic editor directly under 
>> kicad.exe, by-passing
>> eeschema top frame itself, I was exposed to a range of issues in the design 
>> of eeschema.
>>
>> Firstly, I discovered the most excellent work by Wayne Stambaugh regarding 
>> the schematic
>> library containers. 
> 
> Thanks Dick.  I wasn't really expecting any credit.  I was just one of
> those things that needed fixed so I fixed it.  I knew that that only way
> to move Eeschema forward was to fix the underlying library containers.
> I wish I had the time to finish the SCHEMATIC object and come up with a
> better way to handle sheet hierarchies.  With those two pieces of the
> puzzle in place, we could start moving towards the new file format and
> other enhancement that we have discussed over the years.
> 
>>
>> There are a long chain of dependencies here.  LIB_EDIT_FRAME, to come up 
>> first, needs the
>> libraries.  That is obvious in words.  But SCH_EDIT_FRAME typically loads 
>> the libraries
>> before popping up LIB_EDIT_FRAME.  You have a similar discussion about 
>> LIB_VIEW_FRAME.
>>
>> (I believe I solved all these similar problems for PCBNEW.)  So now I went 
>> to solve them
>> for EESCHEMA and produced an 11,000 line patch in 2.5 days.  Remember that 
>> about only
>> 1/7th of a patch line count are actual changed lines.
>>
>> The eeschema libraries were global, even if hidden behind a static class 
>> function, they
>> were global.  This would not dovetail into the notion of multiple open 
>> projects, each
>> having its own set of libraries.  So in the course of moving libraries into 
>> a project
>> specific container, lots of changes were needed.  First among those was to 
>> park the
>> libraries container in the PROJECT.  It was a necessary but insufficient 
>> solution for
>> multiple open projects.  One remaining issue is the fact that with multiple 
>> open projects
>> you'd still have the same library open twice.  Its hard to have the same 
>> problem in
>> PCBNEW, (would have to duplicate project specific libraries) and even if you 
>> did, most of
>> the plugins react to a change on disk and will re-cache if one of the copies 
>> is edited.
>>
>> We now have the libraries container in the PROJECT at least, and it is 
>> loaded on demand,
>> by any _eeschema.kiface KIWAY_PLAYER that needs it.
>>
>> For 5 years or more no one questioned the terminology I introduced in the 
>> SWEET
>> distributed library design regarding the definition of  PART and a 
>> COMPONENT.  The time to
>> object was 5 years ago.  So I went with those original terms per that prior 
>> design.
>> LIB_COMPONENT is now LIB_PART.  SCH_COMPONENT remains.
> 
> Works for me.  I've always thought that LIB_COMPONENT and SCH_COMPONENT
> naming was confusing.
> 
>>
>> SCH_COMPONENT uses a link to a LIB_PART.  That link was previously done by a 
>> library
>> search on every Draw() call.  This was easy since the library container was 
>> global, and
>> the SCH_COMPONENT had access to the global container.  Not so now.
> 
> I seem to remember some other global variables used by the Draw()
> functions.  The color table and possibly some visibility settings come
> to mind.  I don't know if these have any context per project but it may
> be one of those things you want to look out for just in case.
> 
>>
>> This also introduced an avoidable performance hit, which is avoided if a 
>> link to the
>> LIB_PART is retained across SCH_COMPONENT redraws.
>>
>> You can pretty much now tell where this took me.  Squarely into 
>> boost::shared_ptr and it
>> companion class boost::weak_ptr.
>>
>> I will get it working in another half day and push it to its own branch, and 
>> would like
>> folks to use EESCHEMA for a couple of days in that branch.
>>
>> My son and I are doing a very complex board
>> together.
>>
>> And you can load the part editor and footprint editors directly from 
>> kicad.exe, for a
>> single project now.
> 
> Awesome work Dick!  I'll try to do some testing as soon as I see the
> branch on launchpad.
> 
> Wayne


I pushed an early branch of this work to milestoneB.

See the commit log for some of the details.

The shared_ptr turned out to be a can of worms.  No, several cans of worms, all 
stacked
like a 2 miles of dominos.

So I used a s

[Kicad-developers] compiler warning

[Dick Hollenbeck]

Can someone please fix this:


/svn/kicad/product/common/common.cpp:48:13: warning: #warning "You must use
'--with-gnomeprint' or '--with-gtkprint' in your wx library configuration for 
full print
capabilities." [-Wcpp]
 #   warning "You must use '--with-gnomeprint' or '--with-gtkprint' in 
your wx
library configuration for full print capabilities."
 ^
/svn/kicad/product/3d-viewer/vrml_v2_modelparser.cpp: In member function ‘int
VRML2_MODEL_PARSER::read_Transform()’:
/svn/kicad/product/3d-viewer/vrml_v2_modelparser.cpp:160:143: warning: ignoring 
return
value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute 
warn_unused_result
[-Wunused-result]
 fscanf( m_file, "%f %f %f %f", &m_model->m_rotation[0],
&m_model->m_rotation[1], &m_model->m_rotation[2], &m_model->m_rotation[3]);

 ^
/svn/kicad/product/3d-viewer/vrml_v2_modelparser.cpp:167:175: warning: ignoring 
return
value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute 
warn_unused_result
[-Wunused-result]
 fscanf( m_file, "%f %f %f %f", &m_model->m_scaleOrientation[0],
&m_model->m_scaleOrientation[1], &m_model->m_scaleOrientation[2],
&m_model->m_scaleOrientation[3]);


 ^
/svn/kicad/product/3d-viewer/vrml_v2_modelparser.cpp:180:43: warning: ignoring 
return
value of ‘int fscanf(FILE*, const char*, ...)’, declared with attribute 
warn_unused_result
[-Wunused-result]
 fscanf( m_file, "%d", &dummy );
   ^



___
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] 3D modules path strange behaviour

[Dick Hollenbeck]

Wayne,

In our 3/20/2014 "project planning" conversation I mentioned:


   newstring = Prj().Substitute( oldstring );


and 6 or so other suggestions for your project planning document.

Just curious, where is that document, and did these get recorded?

Dick



BTW, the PROJECT::Substitute() function can consult project specific variables, 
and if not
found, it escalates to environment variables.



/**
 * Function Substitute
 * replaces any project variable references found within @a aString with 
their
 * values.  Any referenced variable is first sought in the PROJECT space, 
and if
 * not found, then sought in the environment.
 */
VTBL_ENTRY const wxString Substitute( const wxString& aString );


It should be possible to stuff these variables into the top side of a PROJECT 
using the
python project manager.



___
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] CERN Version 5068 - Cannot load PCB in pcbnew

[Dick Hollenbeck]

This is expected from time to time when loading a board saved with a newer 
version into
older software.

The newer software will load it fine.  If you want the older software to load 
it, then
don't save using the newer software.


___
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] Patches to correct some warnings

[Dick Hollenbeck]

>>
>> No, I passed through that path and rejected it.  Tell the compiler to shut 
>> up.
>>
>>
> 
> Did you happen to check the logic on a C++11 compiler? There is an ifdef on 
> lines 58-60 of the file include/layers_id_colors_and_visibility.h that sets 
> the type of the enum to unsigned char on a C++11 compiler. I suspect that is 
> the cause of the warning, because unsigned isn’t sign extended when it is 
> promoted. The warning saying that the code may not be doing what you intended 
> to do, which is why I brought it up to the list.
> 
> Michael


When we last visited the decision to support C++11, it was a conscious "not 
yet" decision.
 So no, I did not and would not test against C++11, since it is not a current 
objective.

Try making the enum a signed char for your compiler.  If that does not work, 
simply remove
the enum typing and try that.   The size of the enum only saves a few bytes 
when we have
arrays of them, and that is limited.

Again I don't like the patch 4, since I tried that weeks ago and deliberately 
chose to go
a different way.


Your explanations and patch styles were very good BTW.

Dick




___
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] Patches to correct some warnings

[Dick Hollenbeck]

On 07/30/2014 02:51 PM, Michael Narigon wrote:
> All, Here are four patches to correct some warnings I am seeing while 
> compiling with
> the OS X compiler in C++11 mode. I think they have general applicability for 
> all
> targets. I checked that the patches will apply against 5037 and that the 5037 
> programs
> run (on Ubuntu Linux 14.04).
> 
> The first patch fixes a typo in the header guard for
> pcb_calculator/datafile_read_write.h. The typo would cause the guard to fail.
> 
> 
> 
> 
> 
> The second patch fixes some unsigned comparisons in two files with similar 
> logic
> (cvpcb/class_footprints_listbox.cpp and cvpcb/class_library_listbox.cpp.) 
> Linecount is
> an unsigned parameter in these functions. The warning is that the test of 
> linecount >=
> 0 is always true. The code is trying to ensure that linecount is always 
> within the
> range of the array. However, if the array is empty (GetCount == 0) then it 
> could
> subtract 1 from linecount, which would underflow and produce a large positive 
> number,
> not a negative one, since linecount is unsigned.
> 
> 
> 
> 
> 
> The third patch corrects a warning in pcbnew/modview_frame.cpp that the add 
> operator
> doesn’t work as intended with a string and an integer. The patch converts the 
> integer
> to a string prior to the add operator.
> 
> 
> 
> 
> 
> The fourth patch, which I am the least confident of, adds UNSELECTED and 
> UNDEFINED
> enums to the layer list instead of the macro that coerces -1 and -2 to a 
> LAYER_ID. The
> warning I am seeing is that equality comparisons of the layer_id to 
> UNDEFINED_LAYER and
> UNSELECTED_LAYER will never be true. What I am seeing is that the -1 is 
> treated as
> unsigned, which means it has a value of a large positive number (4294967295). 
> Because
> the enum has a type of unsigned char, its max value is 255 so the 4294967295 
> is out of
> range, hence the warning that they will never compare. To fix this, I created 
> enum
> values UNSELECTED and UNDEFINED and gave them values of -2 and -1.  The 
> change fixes
> the warning and doesn’t seem to impact the functioning of the programs, but I 
> don’t
> know for sure what impact the change has across the entire code base.
> 
> 



On 07/30/2014 02:51 PM, Michael Narigon wrote:>
> datafile_read_write.patch
>
>
> === modified file 'pcb_calculator/datafile_read_write.h'
> --- pcb_calculator/datafile_read_write.h  2012-04-02 18:11:00 +
> +++ pcb_calculator/datafile_read_write.h  2014-07-30 01:44:30 +
> @@ -1,5 +1,5 @@
>  #ifndef DATAFILE_READ_WRITE_H_
> -#define PDATAFILE_READ_WRITE_H_
> +#define DATAFILE_READ_WRITE_H_
>  /*
>   * This program source code file is part of KiCad, a free EDA CAD 
> application.
>   *
>
>
>
>
> The second patch fixes some unsigned comparisons in two files with similar 
> logic
(cvpcb/class_footprints_listbox.cpp and cvpcb/class_library_listbox.cpp.) 
Linecount is an
unsigned parameter in these functions. The warning is that the test of 
linecount >= 0 is
always true. The code is trying to ensure that linecount is always within the 
range of the
array. However, if the array is empty (GetCount == 0) then it could subtract 1 
from
linecount, which would underflow and produce a large positive number, not a 
negative one,
since linecount is unsigned.
>
>
> class_listbox.patch
>
>
> === modified file 'cvpcb/class_footprints_listbox.cpp'
> --- cvpcb/class_footprints_listbox.cpp2014-06-04 17:34:23 +
> +++ cvpcb/class_footprints_listbox.cpp2014-07-29 17:46:20 +
> @@ -60,11 +60,13 @@
>
>  void FOOTPRINTS_LISTBOX::SetString( unsigned linecount, const wxString& text 
> )
>  {
> -if( linecount >= m_footprintList.Count() )
> -linecount = m_footprintList.Count() - 1;
> -
> -if( linecount >= 0 )
> +unsigned count = m_footprintList.Count();
> +if( count > 0 )
> +{
> +if( linecount >= count )
> +linecount = count - 1;
>  m_footprintList[linecount] = text;
> +}
>  }


Why, what is the warning?  What is the data type of Count()?




> === modified file 'cvpcb/class_library_listbox.cpp'
> --- cvpcb/class_library_listbox.cpp   2014-06-04 17:34:23 +
> +++ cvpcb/class_library_listbox.cpp   2014-07-29 17:47:47 +
> @@ -60,11 +60,13 @@
>
>  void LIBRARY_LISTBOX::SetString( unsigned linecount, const wxString& text )
>  {
> -if( linecount >= m_libraryList.Count() )
> -linecount = m_libraryList.Count() - 1;
> -
> -if( linecount >= 0 )
> +unsigned count = m_libraryList.Count();
> +if( count > 0 )
> +{
> +if( linecount >= count )
> +linecount = count - 1;
>  m_libraryList[linecount] = text;
> +}
>  }



Again, same questions...


> The third patch corrects a warning in pcbnew/modview_frame.cpp that the add 
> operator
doesn’t work as intended with a string and an integer. The patch converts the 
integer to a
string prior to the add operator.
>
>
> modview_frame.patch
>
>
> === modified fi

Re: [Kicad-developers] PATCH: opening *.pro in current directory gives error message

[Dick Hollenbeck]

> It happened to me when I open kicad on the commandline with a *.pro file in 
> the same
> directory (essentially what jp said)


I missed that since I haven't used kicad.exe that way.

The next step on this topic is to remove all the wxSetWorkingDirectory() calls 
and make
the software work without them.



___
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] PATCH: opening *.pro in current directory gives error message

[Dick Hollenbeck]

On 07/28/2014 08:58 AM, jp charras wrote:
> Le 28/07/2014 15:20, Dick Hollenbeck a écrit :
>> Thanks Henner:
>>
>> I'll look at this now.  The surprise is the inconsistency of the file 
>> dialog, which
>> normally returns a full path, but here not.  An assert would have caught 
>> that assumption,
>> my mistake.
>>
>> In the multiple open projects scenario, changing the directory (CWD) will go 
>> away.
>>
>> So I won't use your patch as is.  But thanks for the diagnosis.
>>
>> PROJECT::SetProjectFullName() requires a full path.  So we'll have to come 
>> up with that.
>>
>> I'll fix this this morning.
>>
>> Dick
> 
> In fact I know one case where a path is not usually given:
> When you run kicad (and only kicad) by hand from a command line and your
> command is:
> kicad myproject.pro
> 
> and myproject.pro is in the cwd.
> 

Henner,

I was unable to duplicate the wxFileDialog behavior but I believe it could be 
version
dependent and needs to be guarded against non-the-less.

I also protect against JP's concern in rev 5033.


I will look at eeschema and pcbnew separately as part of my big pending work.


___
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] PATCH: opening *.pro in current directory gives error message

[Dick Hollenbeck]

Thanks Henner:

I'll look at this now.  The surprise is the inconsistency of the file dialog, 
which
normally returns a full path, but here not.  An assert would have caught that 
assumption,
my mistake.

In the multiple open projects scenario, changing the directory (CWD) will go 
away.

So I won't use your patch as is.  But thanks for the diagnosis.

PROJECT::SetProjectFullName() requires a full path.  So we'll have to come up 
with that.

I'll fix this this morning.

Dick



___
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] can't find kicad.pro

[Dick Hollenbeck]

I'm pretty sure versions newer than 2014-05-31 would tell you where it was 
looking for the
template file, with a popup window.

I've worked the last two days on project related improvements and should have 
those
committed within a couple of days.  I suggest upgrading in about a week.

Until then you might be able to use the programs individually, outside the 
kicad(exe), by
running pcbnew and eeschema directly.

The Kiway architectural changes were most dramatic WRT to project management.
Architectural changes are more dramatic than individual enhancements.

I've found it difficult to spend time on KiCad recently, but did so the last 
two days.

In general if you are going to navigate a storm, you want to be in a fast car.  
That
means, that unless you can build your own binaries, you will not be master of 
your own
destiny.  And of the three platforms, windows, linux and mac, you are using the 
one with
the most grief WRT KiCad support.


Dick




On 07/26/2014 05:50 PM, Jake wrote:
> Hi,
> 
> I'm running kicad (2014-05-31 BZR 4902)-product on MacOS from a build I 
> downloaded and i'm having a serious problem.
> 
> It's been working fine for a while, i have made boards and done some work 
> with it.  But i was never able to create a new project, either blank or 
> from a template.  It always said "Error:  Can't find kicad.pro" or 
> something like that.  (Sorry, it doesn't allow me to copy text from the 
> error dialog for some reason, although i can highlight the text)
> 
> but today I was asking on IRC where i'm supposed to find or put kicad.pro 
> on the mac, and to describe the error i tried again to make a new project 
> and it gave me the error "InfoProject template file  not 
> found."
> 
> and then i quit kicad thinking nothing had changed.  But now, if i try to 
> open kicad, it just says "Error Unable to find kicad.pro template config 
> file." and clicking OK just repeats the error.  If you hold down the enter 
> key, it clicks OK 30 times a second.  Forever.
> 
> all the menus are greyed out, there's no option to quit or open a 
> different project or anything.  I have to force-quit kicad from the 
> operating system (command-option-escape) which is like kill -9
> 
> help!  i have no idea what to do, or what config file got changed or what.
> 
> help?
> 
> -jake



___
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] issue with sscanf %lf vs %f

[Dick Hollenbeck]

On 07/26/2014 03:36 PM, Mário Luzeiro wrote:
>> Line 50 of 3d-viewer/3d_struct.h shows that the recipient data item is 
>> double.
>> Could it be somebody changed line 50 from:  double x, y, z;
> 
> yes, myself :S sorry, I've now fixed it myself.
> 
> I changed S3D_VERTEX to glm::vec3 so I can use the glm library 
> functionalities.
> 
> Do you have in mind any other places that this can cause any issue?
> 
> Mario Luzeiro


I rarely use "float" data type, almost always "double" these days.

But I cannot answer your question since you used the pronoun "this" and I am 
terrible at
mapping pronouns to actual nouns.  My mind doesn't like ambiguity, too many 
years of
programming.


Dick




___
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] issue with sscanf %lf vs %f

[Dick Hollenbeck]

On 07/26/2014 02:53 PM, Mário Luzeiro wrote:
> Hi all,
> 
> I notice that in my system, I have problems parsing data with actual %lf 
> notation that kicad is using.
> I got warnings about it when it is building, complaining that it is expecting 
> a double but it is parsing to float.


Line 50 of 3d-viewer/3d_struct.h shows that the recipient data item is double.


I don't use sscanf() myself, preferring strtod().  But I don't understand the 
problem.
Could it be somebody changed line 50 from:

double x, y, z;

?


___
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] Speed up building?

[Dick Hollenbeck]

On 07/25/2014 03:59 AM, Mário Luzeiro wrote:
> Hello,
> Is is possible speed up building (in linux) some how? (without to buy a 
> faster computer)
> It looks it is not building using multiprocessor.
> 
> Also, every small change, it will took a lot of time by the linker to do its 
> business.
> I do believe the only way would be implement dynamic objects or someting but 
> it will change drastically the architecture. :/
> 
> MRL

Some tips:

**) if you are editing a header file, this is typically to change the behaviour 
of one
*.cpp file of immediate concern.  So compile that *.cpp module first, rather 
than letting
the makefile decide to compile everything that depends on the header first.  
After your
header file edits compile in the context of that one *.cpp module of immediate 
concern,
then compile the rest of the link image.

Example:

$ cd build-debug/kicad   ( I am working on kicad.exe, not pcbnew, eeschema, 
cvpcb, etc. )

$ make help | grep config
... prjconfig.o
... prjconfig.i
... prjconfig.s

This means I can make prjconfig.o explicitly *first*.

$ make prjconfig.o

When that makes/compiles, it proves my header file edits are good to go for the 
rest of
the link image, so now I only build kicad(exe), since that is what I am working 
on:

$ make kicad -j4

When done, at end of day or for patch preparation, then build the whole project:

$ cd ..   back up to build-debug
$ make -j4
$ bzr diff > /tmp/patch


==

**) This discussion would not be complete without mentioning the obvious fact 
that a
faster computer does build the system faster.   This is actually the most 
important fact
to consider and tackle.

There are handicaps in golf.  I know of no sporting reason to have them in 
software
development.

And the cost of the computer is typically one of those famous self regulating 
problems:

The guy at the keyboard's time will tend to be valued according to its actual 
value in the
marketplace.


Dick


___
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] Display issue with blind/buried vias

[Dick Hollenbeck]

On 07/22/2014 06:43 PM, Andrew Zonenberg wrote:
> Proposed fix attached.
> 
> With this patch, vias are displayed if
> a) via display is turned on, and
> b) at least one of the layers the via crosses is displayed.

Hi Andrew,

Thanks for the idea and the patch.  The patch has tabs in it and trailing 
whitespace.
So its best not to fight your text editor in this way.  The human will always 
forget.
Simply change your editor's settings instead.


I'd also like not expose the "for loops", but rather use VIA::GetLayerSet() 
which has
capabilities for caching in the future and hides information in general.


Please try the attached patch instead, and notice any formatting differences.


Dick


=== modified file 'pcbnew/class_pcb_layer_widget.cpp'
--- pcbnew/class_pcb_layer_widget.cpp	2014-07-20 17:41:12 +
+++ pcbnew/class_pcb_layer_widget.cpp	2014-07-23 14:21:05 +
@@ -413,6 +413,7 @@
 {
 KIGFX::VIEW* view = galCanvas->GetView();
 view->SetLayerVisible( aLayer, isVisible );
+view->RecacheAllItems( true );
 }
 
 if( isFinal )

=== modified file 'pcbnew/class_track.cpp'
--- pcbnew/class_track.cpp	2014-06-30 05:46:18 +
+++ pcbnew/class_track.cpp	2014-07-23 14:28:15 +
@@ -393,17 +393,12 @@
 
 // VIA_BLIND_BURIED or VIA_MICRVIA:
 
-LAYER_ID bottom_layer, top_layer;
-
-// LayerPair() knows how layers are stored
-LayerPair( &top_layer, &bottom_layer );
-
 LSET layermask;
 
-wxASSERT( top_layer <= bottom_layer );
+wxASSERT( m_Layer <= m_BottomLayer );
 
 // LAYER_IDs are numbered from front to back, this is top to bottom.
-for( LAYER_NUM id = top_layer;  id <= bottom_layer;  ++id )
+for( LAYER_NUM id = m_Layer;  id <= m_BottomLayer;  ++id )
 {
 layermask.set( id );
 }
@@ -780,13 +775,17 @@
 
 GRSetDrawMode( aDC, aDrawMode );
 
-BOARD * brd =  GetBoard( );
-EDA_COLOR_T color = brd->GetVisibleElementColor(VIAS_VISIBLE + GetViaType());
+BOARD * brd =  GetBoard();
+EDA_COLOR_T color = brd->GetVisibleElementColor( VIAS_VISIBLE + GetViaType() );
 
 if( brd->IsElementVisible( PCB_VISIBLE(VIAS_VISIBLE + GetViaType()) ) == false
 && ( color & HIGHLIGHT_FLAG ) != HIGHLIGHT_FLAG )
 return;
 
+// Only draw the via if at least one of the layers it crosses is being displayed
+if( !( brd->GetVisibleLayers() & GetLayerSet() ).any() )
+return;
+
 if( DisplayOpt.ContrastModeDisplay )
 {
 if( !IsOnLayer( curr_layer ) )

=== modified file 'pcbnew/pcb_painter.cpp'
--- pcbnew/pcb_painter.cpp	2014-07-21 10:54:58 +
+++ pcbnew/pcb_painter.cpp	2014-07-23 14:27:48 +
@@ -336,6 +336,11 @@
 VECTOR2D center( aVia->GetStart() );
 double   radius;
 
+// Only draw the via if at least one of the layers it crosses is being displayed
+BOARD*  brd =  aVia->GetBoard( );
+if( !( brd->GetVisibleLayers() & aVia->GetLayerSet() ).any() )
+return;
+
 // Choose drawing settings depending on if we are drawing via's pad or hole
 if( aLayer == ITEM_GAL_LAYER( VIA_THROUGH_VISIBLE ) )
 {

___
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] Segfault in BOARD::ReplaceNetlist()

[Dick Hollenbeck]

On 07/21/2014 10:32 AM, Andrew Zonenberg wrote:
> I can't share the board unfortunately since it's a project for work. I
> do have a core dump that I can poke around in and give you info for, as
> well as see if I can reproduce it on some of the open-source designs I'm
> working on.

That would not be enough for me.  Sorry I cannot help you.
Maybe someone else can.

Dick


___
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] Segfault in BOARD::ReplaceNetlist()

[Dick Hollenbeck]

I could not duplicate this with the one and only board I tried it with.
You may have to zip up the board and netlist file, at least.


___
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] bugs on mac install of kicad / libraries

[Dick Hollenbeck]

On 07/21/2014 12:13 AM, Jake wrote:
> i downloaded a zip of a build for macOS containing KiCad 2014-05-31 BZR 
> 4902-product (called "Kicad-product-2014-05-31.zip")
> 
> I can't remember where I downloaded it though, and the official kicad page 
> at http://www.kicad-pcb.org/display/KICAD/Download leads to source (very 
> difficult to build on macos) or packages that are quite old.
> 
> so on to my problems.  Installing libraries was very difficult because the 
> "sed" command on bsd does not support extended regex (the -r parameter) 
> and sed is used by library-repos-install.sh to create a list of libraries 
> to download.
> 
> perhaps macOS after 10.6.7 has a version of sed that allows for -r 
> extended regex?  If not, the command
> sed  's:.+ "KiCad/(.+)",:\1:'
> should be replaced with
> sed 's:..KiCad/::' | sed 's:\",::'
> in library-repos-install.sh


This "patch" does not make any sense to me.

Just fix your copy and move on.  This is a one off.  Most MAC users will use 
the github
plugin anyways.

Playing dumb-down to the lowest common denominator gets old sometimes.

Give Apple a phone call and have them fix their sed.

Nobody has the time to test the patch, and then go batshit when it breaks the 
linux install.

Dick



___
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