Re: [Kicad-developers] [Bug 1545468] Re: CK1202_V1.pcb: distribution of non-free file in examples
OK. I think we can rely on a preserved copy of the file in the Kicad repo history where from it can be recovered in case of unavailability of the file in the origin (http://www.pcadbegin.webtm.ru/schetchik.php?scach=1). New demo files are fine, however CK1202_V1.pcb, as I said, is still used for regression testing in case of pcad2kicad source code modification/enhancement. Best regards,Alexander. On Monday, February 22, 2016 10:41 PM, jp charras <jp.char...@wanadoo.fr> wrote: Le 22/02/2016 20:07, Alexander Lunev a écrit : > Hi all, I do not fully understand why this file should be removed. > Jean-Pierre, initially YOU suggested me to upload 1 or 2 demo board > files to allow developers to test pcad2kicad import (see your e-mail > dated 28-Jun-2012). I considered your suggestion reasonable and tried > to search for demo files in the Internet. I found only one here: > http://www.pcadbegin.webtm.ru/schetchik.php?scach=1 To commit this > demo file, first I requested a permission from the author, Andrey > Manin. I got his permission by e-mail on 06-Aug-2012. As I uploaded > that demo file, it has been already using for regression testing. > > Best regards, Alexander. Yes, I remember, and thanks you to take the time to find an available test file. Looks like sometimes, Linux maintainers are picky about licenses. Because the license of this file is unknown (no info about this license on the Andrey Manin's site) and to avoid questions about licenses of a few files again and again, I removed it although I am thinking there is no problem about the license of this file. (An other doc file was removed for this reason) However the link to this file is in the file pcbnew/pcad2kicad_plugin/files.txt. We also have now a few other files available on the kicad bug tracker, so this file, which was very useful for testers some times ago, is now not so important for tests (it was more important when the plug-in was written). -- Jean-Pierre CHARRAS ___ 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] Static initialization order fiasco
Probably won't let you know. Instead we'll just fix them.
OK. Thanks.
On Sunday, April 13, 2014 1:43 AM, Dick Hollenbeck d...@softplc.com wrote:
On 04/12/2014 02:56 PM, Alexander Lunev wrote:
This week I tried to build recent revisions of KiCad. Every attempt I built
them, Pcbnew
fell with segmentation fault. I tried different versions of wxWidgets with
different
options. It did not help. It was especially strange because other developers
told me that
they can build and run the same revision (e.g. revision 4751) of Pcbnew
normally.
As it turned out, the issue is with undefined static initialization order.
lp:kicad revision 4792 and earlier:
class_netclass.cpp (line 39):
const wxString NETCLASS::Default = wxT(Default);
class_netinfolist.cpp (line 283):
NETINFO_ITEM NETINFO_LIST::ORPHANED = NETINFO_ITEM( NULL, wxEmptyString,
NETINFO_LIST::UNCONNECTED );
class_netinfo_item.cpp (line 52...):
NETINFO_ITEM::NETINFO_ITEM( BOARD_ITEM* aParent, const wxString aNetName,
int aNetCode ) :
m_NetCode( aNetCode ), m_Netname( aNetName ), m_ShortNetname(
m_Netname.AfterLast( '/' ) )
{
m_parent = aParent;
m_RatsnestStartIdx = 0; // Starting point of ratsnests of this net in
a
// general buffer of ratsnest
m_RatsnestEndIdx = 0; // Ending point of ratsnests of this net
m_NetClassName = NETCLASS::Default; // ! here NETCLASS::Default may
not be yet
initialized !
m_NetClass = NULL;
}
Nice catch.
If there are other known similar places in the project, please, let us know.
Probably won't let you know. Instead we'll just fix them.
I have removed tons of static constructors in the last month, I'm sure over
200. And even
more last night.
This is a reversal in trend however, in a positive direction.
BTW, this is not a fiasco. Its just another of several bugs.
It is difficult enough to review the whole project visually and moreover such
bugs are subtle.
Alexander
___
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
[Kicad-developers] Static initialization order fiasco
This week I tried to build recent revisions of KiCad. Every attempt I built
them, Pcbnew fell with segmentation fault. I tried different versions of
wxWidgets with different options. It did not help. It was especially strange
because other developers told me that they can build and run the same revision
(e.g. revision 4751) of Pcbnew normally.
As it turned out, the issue is with undefined static initialization order.
lp:kicad revision 4792 and earlier:
class_netclass.cpp (line 39):
const wxString NETCLASS::Default = wxT(Default);
class_netinfolist.cpp (line 283):
NETINFO_ITEM NETINFO_LIST::ORPHANED = NETINFO_ITEM( NULL, wxEmptyString,
NETINFO_LIST::UNCONNECTED );
class_netinfo_item.cpp (line 52...):
NETINFO_ITEM::NETINFO_ITEM( BOARD_ITEM* aParent, const wxString aNetName, int
aNetCode ) :
m_NetCode( aNetCode ), m_Netname( aNetName ), m_ShortNetname(
m_Netname.AfterLast( '/' ) )
{
m_parent = aParent;
m_RatsnestStartIdx = 0; // Starting point of ratsnests of this net in a
// general buffer of ratsnest
m_RatsnestEndIdx = 0; // Ending point of ratsnests of this net
m_NetClassName = NETCLASS::Default; // ! here NETCLASS::Default may not
be yet initialized !
m_NetClass = NULL;
}
If there are other known similar places in the project, please, let us know. It
is difficult enough to review the whole project visually and moreover such bugs
are subtle.
Alexander___
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] About the new Pl_Editor tool.
EESchema crashes: cmake ../ -DKICAD_GOST=ON -DCMAKE_BUILD_TYPE=Debug -DwxWidgets_USE_DEBUG=ON -DKICAD_TESTING_VERSION=ON a-lunev@debian-notebook:~/bzr/kicad/Debug/eeschema$ ./eeschema 10:24:05: Debug: Adding locale lookup path: /usr/local/share/kicad/internat ../src/common/filefn.cpp(251): assert !fn.IsDir() failed in FindValidPath(): Cannot search for directories; only for files Trace/breakpoint trap Application: KiCad Version: (2013-07-22 BZR 4245 GOST)-testing Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.4.5,wx containers,compatible with 2.8) Platform: Linux 2.6.39-bpo.2-amd64 x86_64, 64 bit, Little endian, wxGTK Boost version: 1.53.0 Options: USE_PCBNEW_NANOMETRES=ON KICAD_GOST=ON USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF Debian 6.0.7 (Squeeze). Also I tried to build as follows: cmake ../ -DKICAD_GOST=ON -DCMAKE_BUILD_TYPE=Release -DKICAD_TESTING_VERSION=ON In this case there is no problem. From: jp charras jp.char...@wanadoo.fr To: kicad-developers@lists.launchpad.net Sent: Monday, July 22, 2013 11:02 PM Subject: [Kicad-developers] About the new Pl_Editor tool. I released the first draft of Pl_Editor, a new tool to create customized title blocks. Some features are still missing (like hot keys and undo/redo commands) but it should be very usable. The documentation is also released. Please read it. I need volunteers to test it. I need mainly GOST users to create a GOST title block (with an English version to test it). I am thinking most of features needed by GOST title blocks are existing, but let me know if something is missing to create GOST title blocks. I want (in the *very* next future) to remove all GOST conditional compilation in Kicad core code, because currently there are only 2 specific GOST feature: - The first (parts id notation) is now available as config option in Eeschema (with more than only GOST notation). - The second is the GOST title block. The code relative to GOST title block is *very poor* and not maintainable, and not compatible with the title block editor, and the new customizable title block mechanism is by far more powerful. I am thinking GOST title block is just a customized title block, like many other title blocks used in many companies, and therefore does not need a specific code inside Kicad. Thanks for your help. -- Jean-Pierre CHARRAS ___ 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] /include/xnode.h giving warnings
Yes, it's my fault.
Would somebody with a write access add 'return' in line 118 of xnode.h?
Best regards,
Alexander
From: Edwin van den Oetelaar oetelaar.automatiser...@gmail.com
To: KiCad Developers kicad-developers@lists.launchpad.net
Sent: Thursday, June 13, 2013 11:28 AM
Subject: [Kicad-developers] /include/xnode.h giving warnings
I am still on Wx 2.8 and building gave me lots of warnings about no
return() from non void function.
Possible fix here.
Greetings,
Edwin van den Oetelaar
bzr diff include/
=== modified file 'include/xnode.h'
--- include/xnode.h 2013-06-12 19:43:22 +
+++ include/xnode.h 2013-06-13 07:25:23 +
@@ -118,7 +118,7 @@
}
bool DeleteAttribute( const wxString attrName )
{
- DeleteProperty( attrName );
+ return DeleteProperty( attrName );
}
wxXmlProperty* GetAttributes() const
{
___
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] /include/xnode.h giving warnings
In line 121. I'm sorry, I had too little sleep last night.
From: Alexander Lunev al.lu...@yahoo.com
To: KiCad Developers kicad-developers@lists.launchpad.net
Sent: Thursday, June 13, 2013 12:46 PM
Subject: Re: [Kicad-developers] /include/xnode.h giving warnings
Yes, it's my fault.
Would somebody with a write access add 'return' in line 118 of xnode.h?
Best regards,
Alexander
From: Edwin van den Oetelaar oetelaar.automatiser...@gmail.com
To: KiCad Developers kicad-developers@lists.launchpad.net
Sent: Thursday, June 13, 2013 11:28 AM
Subject: [Kicad-developers] /include/xnode.h giving warnings
I am still on Wx 2.8 and building gave me lots of warnings about no
return() from non void function.
Possible fix here.
Greetings,
Edwin van den Oetelaar
bzr diff include/
=== modified file 'include/xnode.h'
--- include/xnode.h 2013-06-12 19:43:22 +
+++ include/xnode.h 2013-06-13 07:25:23 +
@@ -118,7 +118,7 @@
}
bool DeleteAttribute( const wxString attrName )
{
- DeleteProperty( attrName );
+ return DeleteProperty( attrName );
}
wxXmlProperty* GetAttributes() const
{
___
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
[Kicad-developers] License mismatch
For some reason, the license in COPYRIGHT.txt differs from license in most of KiCad source files, including menu: Help-About...-License. COPYRIGHT.txt has LGPL ver.2 text. This has confused me once again. Alexander___ 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] The developer mailing list did not work in my case
Note: we have feedback from users/developers only for the Eagle importer. I have got that feedback. Users/developers communicate with me directly. If pcad2kicadsch was in lp:kicad, I think they would send reports to the developer mailing list instead. My resentment is not about lp:kicad/stable but lp:kicad. P.S.: Jean-Pierre, I think you had better openly tell about your / lp:kicad team intentions concerning KICAD_GOST here, on the developer mailing list. Who is silent about intentions, again me? GOST users/developers should know this and act correspondingly. Alexander.___ 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] The developer mailing list did not work in my case
Jean-Pierre and Wayne, you have let me know that the root of the problem is I was silent about my intentions. The short review of what happened: 1) [31 Aug 2008]: https://lists.launchpad.net/kicad-developers/msg01689.html ... I think, for users, better to have something than nothing! Is it required to have a different homepage for pcad2kicad? May be better to integrate it directly in to the KiCad? ... Igor Plyatov Would anybody object if PCAD to KiCad converter were integrated to KiCad? Alexander Lunev 2) Dick Hollenbeck wrote: No objection from me. So only Dick responded. It was clear to me that nobody disagreed. Unfortunately the long break took place here. 3) [08 Jun 2012]: I started to rewrite pcad2kicad from Delphi to c++. 4) [10 Jun 2012]: https://lists.launchpad.net/kicad-developers/msg08429.html Alexander Lunev wrote: Hi. Would you add me to the team? 5) [11 Jun 2012]: https://lists.launchpad.net/kicad-developers/msg08435.html Alexander Lunev wrote: I had been granted a write permission to Kicad SVN repository since 2008. At the same time I was involved to pcad2kicad project and added polygons support. pcad2kicad is mostly written in Delphi. It was agreed to rewrite pcad2kicad in C++ in order to integrate it into Kicad and provide the opportunity for more people to be involved in the developing process. Unfortunately, since that time both the former of pcad2kicad and I had had no spare time to continue the development. But now I have just started to develop a new device and I want to use Kicad for that. So I need to convert some libraries into Kicad and decided to resume my plans with pcad2kicad converter. That is why I created the pcad2kicad branch that you noticed some days ago. P.S. Several weeks ago I tried to find Kicad project in old locations, firstly on the sourceforge.net Wiki. But there are some issues. As I understood, Kicad developing group was removed from Yahoo and I do not know why. I think I missed much. And now I see that Kicad is on Launchpad and Bazaar repo is used where I have not got the write permission. So there are many surprises to me. No reaction except Miguel Angel Ajo Pelayo. 6) [15 Jun 2012]: I completed rewriting pcad2kicad from Delphi to c++ and fixed the main bug concerning the recursion. At this point pcad2kicad was ready to use. I requested merge with lp:kicad. 7) [24 Jun 2012]: I received Wayne's respond: PCAD import support would be a welcome addition to KiCad but I am not thrilled about adding another stand alone executable to KiCad. My preference would be to add a PCAD plug-in to Pcbnew... 8) [25 Jun 2012]: I asked Wayne: What about translating P-Cad libraries? No reaction. 9) [27 Jun 2012]: I decided to agree and started to rewrite pcad2kicad to make it Pcbnew plugin. 10) [07 Jul 2012]: I published eeschema-plugin blueprint: https://blueprints.launchpad.net/kicad/+spec/eeschema-plugin and assigned Jean-Pierre as an approver: This Eeschema plug-in is necessary to support new ones such as Eagle, P-Cad and other plug-ins for Eeschema. It is supposed that the Eeschema plug-in mechanism needs to be very similar to the one implemented in Pcbnew. No reaction. 11) I continued trying to agree with Wayne and Jean-Pierre fulfilling their ideas again and again. Every time I tried to believe that all will be OK. 12) 6 months passed and at last Jean-Pierre merged pcad2kicadpcb to lp:kicad! For some unknown to me reason pcad2kicadsch is still not merged into lp:kicad! Today is 15 May, 2013. Moreover, still there is not a write access to lp:kicad! The same ignoring situation is with GOST-doc-gen and the component manager. I have ultimately stopped hoping anything positive from the team. Alexander___ 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] P-Cad plug-in
The concept you are expressing is quite attractive. However, all the things will work in case of 100% precision of round trip conversion. Even if we had as little as 1% conversion error then, from my point of view, it would be bad idea to write footprints back in situ. Imagine that you can validate your written-back footprint by means of KiCad, however you do not have an opportunity to validate it by the original proprietary CAD because you do not own that CAD and have not got access to it. Although the written-back footprint is well displayed in KiCad, you do not know how it will be actually displayed in the original CAD. The problem is that we can not make 100% precise converter right now. It will take indefinite period of time to complete it, to eliminate all the possible bugs and inaccuracies. Thus it prevents me and someone else from using such converter for years because I can neither write it back nor save it in a new place in KiCad format. On the other hand, I could use not 100% accurate converter and save the result in KiCad format. This would allow me to move forward. Best regards, Alexander Lunev From: Dick Hollenbeck d...@softplc.com To: Alexander Lunev al.lu...@yahoo.com Cc: kicad-developers@lists.launchpad.net kicad-developers@lists.launchpad.net Sent: Saturday, June 30, 2012 8:05 PM Subject: Re: [Kicad-developers] P-Cad plug-in On 06/30/2012 06:04 AM, Alexander Lunev wrote: Thank you for the comprehensive reply. On 06/27/2012 02:13 AM, Dick Hollenbeck wrote: The library table allows concurrent use of PLUGIN::Footprint*() functions from multiple alternative technologies. It means you in theory would not need to convert PCAD, *.mod, *.kicad_mod, or eagle footprints, but rather you could use and edit them in situ, as if they were equivalently valid footprints for Pcbnew. As I understand it actually works in theory only. If I ultimately convert some heterogeneous library to KiCad and somehow save it into new representation, say SWEET, then in most cases I will need to manually correct the new saved library components in order to fit their drawings in appropriate or better positions because of distortion caused by the conversion (positioning errors, shape approximation etc.) Moreover I can not imagine how to edit components in heterogeneous library in situ by means of KiCad not spoiling them because of distortion caused by import/export on-the-fly. Even though you edit the heterogeneous components in situ and manually edit/adapt them to KiCad, these components will no longer be well representable in the original (heterogeneous) CAD. Do I understand you right concerning 'in situ'? Can we talk about one program at a time? Let's focus on Pcbnew, for which the PLUGIN interface exists. Eeschema is for another day, and I don't think it is pertinent yet. What you are saying will be fractionally true, with different magnitudes of truth depending on the foreign EDA tool, and to the extent that each foreign tool has features that Pcbnew footprints do not support in its footprints. I don't see where rounding of numbers enters into it, since we now go to nanometer resolution. The greater the compatibility in footprint features, the greater the ability to round trip footprints. In the case of Eagle, I did not see anything preventing us from writing FootprintSave() and FootprintLoad() and actually using Eagle footprints almost as well as they do, including editing them. In situ means in place. This means just use eagle footprints where they live, say under the Eagle directory elsewhere on your hard drive, no need to convert them to a different file format. Also keep in mind that: a) because the PLUGIN::Footprint*() functions position the MODULE as the go between entity, the design encourages the enhancement of MODULE to accomadate features from other EDA tools that we currently do not support. b) most of the time footprints are read only entities, for if they were not, why in the world would the default install of footprint libraries on linux do so into a read only directory? c) If you can read a footprint well enough to convert it, you can read it well enough to certainly use it without writing back to disk other than in a BOARD via instantiation. d) If you can read a footprint well enough to convert it, often you can figure out how to write it back out in the foreign format. Two reasons why you might WANT to do this are: 1) you intend to inter-operate with a community of designers using that foreign tool, 2) you would like them to eventually feel comfortable enough with KiCad to convert. This is not particularly different than what Open Office has done. They have supported both read and write capability in many different file formats. e) There is Pcbnew code to load a geda footprint now, if it was put into a PLUGIN, then you'd have read only capability to use those
Re: [Kicad-developers] P-Cad plug-in
Thank you for the comprehensive reply.
On 06/27/2012 02:13 AM, Dick Hollenbeck wrote:
The library table allows concurrent use of PLUGIN::Footprint*() functions
from multiple
alternative technologies. It means you in theory would not need to convert
PCAD, *.mod,
*.kicad_mod, or eagle footprints,
but rather you could use and edit them in situ, as if they were equivalently
valid
footprints for Pcbnew.
As I understand it actually works in theory only. If I ultimately convert some
heterogeneous library to KiCad and somehow save it into
new representation, say SWEET, then in most cases I will need to manually
correct the new saved library components in order to fit their
drawings in appropriate or better positions because of distortion caused by the
conversion (positioning errors, shape approximation etc.)
Moreover I can not imagine how to edit components in heterogeneous library in
situ by means of KiCad not spoiling them because of
distortion caused by import/export on-the-fly. Even though you edit
the heterogeneous components in situ and manually edit/adapt them to
KiCad, these components will no longer be well representable in the original
(heterogeneous) CAD.
Do I understand you right concerning 'in situ'?
Best regards,
Alexander Lunev
From: Dick Hollenbeck d...@softplc.com
To: kicad-developers@lists.launchpad.net
Sent: Wednesday, June 27, 2012 2:13 AM
Subject: Re: [Kicad-developers] P-Cad plug-in
On 06/26/2012 02:23 PM, Alexander Lunev wrote:
It was suggested to implement pcad2kicad converter as pcbnew plug-in. It is
clear how to do this in the case of pcbnew. Even it is clear
how to do this in the case of eeschema. But it is not clear what to do with
translation of P-Cad libraries (pcb and schematic libraries).
Now there are 4 different modes in pcad2kicad converter: converting pcb
design files, converting pcb library files, converting sch design
files and converting sch library files. Considering the user interface how
the converting libraries could be implemented applied to KiCad?
Any considerations?
Here are a couple of alternative plans for the *Pcbnew* portion of the
problem/opportunity. The degree of thoroughness can vary because Pcbnew PLUGIN
can be implemented to varying degrees. If you do not implement a function this
is not a
fatal problem.
Elaborate Plan:
==
a) Implement *all* the functions in PCAD_PLUGIN, especially all
PCAD_PLUGIN::Footprint*().
b) Also implement a library table for Pcbnew, see new/sch_lib_table.h and
new/sch_lib_table.cpp as the basis of
some new similar class, but you replace LIB_TABLE::ROW::lib with a PLUGIN*
pointer. This
architecture
replaces the Pcbnew library search path design with a library table design. An
initial
library table could
simply be an s-expression text file, like is being parsed for SWEET already.
Could use
that parser as as starting point, its done, it works.
The library table allows concurrent use of PLUGIN::Footprint*() functions from
multiple
alternative technologies. It means you in theory would not need to convert
PCAD, *.mod,
*.kicad_mod, or eagle footprints,
but rather you could use and edit them in situ, as if they were equivalently
valid
footprints for Pcbnew.
Mid-level Plan:
a) Implement just the Load() Footprint{Load,Enumerate}() read only type
functions.
b) Also implement the library table as above. But hard code any writing of
footprints
back through the new KICAD_PLUGIN.
This basically gives you a read only or edge triggered conversion of
footprints, but lets
you access them natively in situ.
Lazy Plan:
==
a) Implement just the Load() Footprint{Load,Enumerate}() read only type
functions.
b) Use Miguels scripting to convert from PCAD to s-expression both boards and
footprints
on the assumption that the scripting housing could simaltaneously manage two
plugins.
Read a footprint, write a footprint. Read a board, write a board. You bother
with
scripting because its going to happen again on the next PLUGIN.
One of the most frequently reported bug reports that has been seen over the
last five
years is the library search path. I don't like that design and never have.
Obviously I have thought that the library table concept is better, since that
is what I
had coded for SWEET. You can actually see it in operation if you single step
through the SWEET test program. The key to it is the logical library name.
In Pcbnew
you have something like a shortened library name in the UI already, and it is
currently
the last part of the library path. With the library table, it becomes more
meaningful, it
is an index into the library table.
So if you can see the value in the library table concept, it needs to come in
even on its
own merits, aside from this discussion. Once there is buy in for that,
then the Mid-level Plan starts looking pretty doable for footprint access.
In all cases, just having
[Kicad-developers] P-Cad plug-in
It was suggested to implement pcad2kicad converter as pcbnew plug-in. It is clear how to do this in the case of pcbnew. Even it is clear how to do this in the case of eeschema. But it is not clear what to do with translation of P-Cad libraries (pcb and schematic libraries). Now there are 4 different modes in pcad2kicad converter: converting pcb design files, converting pcb library files, converting sch design files and converting sch library files. Considering the user interface how the converting libraries could be implemented applied to KiCad? Any considerations? Best regards, Alexander Lunev ___ 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] Why ALL capital letters for classes and typedefs
The KiCad coding style policy contains the requirement: Class, typedef, enum, name space, and macro names should be comprised of all capital letters. My question is why should CLASSES and TYPEDEFs be comprised of ALL capital letters? What is the reason for that? The most common convention that I have ever seen before sounds like: A class name should begin with a capital letter and be written in mixed case (e.g., String). If a class name consists of more than one word, each word should begin with a capital letter (e.g., StringBuffer). If a class name, or one of the words of a class name, is an acronym, the acronym can be written in all capital letters (e.g., URL, HTMLParser). Best regards, Alexander Lunev___ 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] Why ALL capital letters for classes and typedefs
I believe most developers agree to follow some project predetermined coding style policy... According to the KiCad coding style policy, constants and macro names should be comprised of all capital letters (it is common, that is OK). However, according to the policy, classes and typedefs should be designated in the same way (all capital letters). So it is easier to get confused while reading the source code, especially for developers who get used to names written in all capital letters and implied as either constants or macros. As for me, wxSomeClass and kiSomeClass names are quite good ones. I think these examples are still in conformance with the common convention. wx and ki are just prefixes to highlight a subset of classes. Also as you said it is good practice to use members variables starting with m_ but there is no mention of it in the KiCad coding style policy. Alexander Lunev From: jean-pierre charras jp.char...@wanadoo.fr To: kicad-developers@lists.launchpad.net Sent: Friday, June 22, 2012 8:44 PM Subject: Re: [Kicad-developers] Why ALL capital letters for classes and typedefs Le 22/06/2012 10:16, Lorenzo Marcantonio a écrit : On Fri, Jun 22, 2012 at 01:02:18AM -0700, Alexander Lunev wrote: The KiCad coding style policy contains the requirement: Class, typedef, enum, name space, and macro names should be comprised of all capital letters. My question is why should CLASSES and TYPEDEFs be comprised of ALL capital letters? What is the reason for that? The most common convention that I have ever seen before sounds like: A class name should begin with a capital letter and be written in mixed case (e.g., String). If a class name consists of more than one word, each word should begin with a capital letter (e.g., StringBuffer). If a class name, or one of the words of a class name, is an acronym, the acronym can be written in all capital letters (e.g., URL, HTMLParser). Well that's not the strangest coding convention in kicad :P just ask our tyrannical leaders, they'll just say they can't read them otherwise. Oh well, I've no issues with that... First of all KiCad coding style is not a whim of developers, and it is not intended to be the best rules never seen to write code. It is a set of rules to keep KiCad sources easy to read and maintain. The first requirement is all sources should have the same look. Therefore KiCad coding style define a set of rules to do that. Class, enum ... names must have a style (the same in all files). You can use: - names starting with a capital letter and written in mixed case. - names starting always by a given prefix like ki or Ki or KI for kicad (like in wxWidgets). - names in capital letters only and much more. By a decision must be taken: it was names in capital letters only The advantage is class names area easy to identify when reading a file, because other words are not capitalized. Some others tricks are used to easily identify variables: argument variables have a name starting by 'a' (like aCount, aValue) local variables have the first letter never capitalized ( countmax or countMax) global variables have the first letter always capitalized ( Countmax or CountMax) class members variables have a name starting by m_ ( m_count, m_Count ) public members variables have the first letter after m_ always capitalized (m_Count) public members variables have the first letter after m_ always not capitalized (m_count) or just written like local variables (count) . ( I prefer the name m_count to count ) See KiCad coding style for many other rules. Developers *know* other rules are widely used, but to write KiCad coding style decisions must be taken. Rules in KiCad coding style are not always rules used by some contributors when they are not working on KiCad, but I am thinking KiCad coding style should be acceptable by everybody. Strange coding convention is usually coding conventions used by others Therefore there is a *lot* of Strange coding conventions (usually coding conventions that do not match *my* coding convention) At last, the best answer to Why should CLASSES and TYPEDEFs be comprised of ALL capital letters could by: why not? Thanks to developers who carefully read the KiCad coding style rules. I am sure you could find some good ideas inside. -- Jean-Pierre CHARRAS ___ 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] Clearance and rounding in kicad-nano
miguelan...@nbee.es wrote: ... We have a big dependency to a closed software because of freerouter. If Alfon shuts it down at any time, for any reason, and we have lost our basic skills... then you couldn't route. absolutely agree. From: Miguel Angel Ajo Pelayo miguelan...@nbee.es To: Dick Hollenbeck d...@softplc.com Cc: kicad-developers@lists.launchpad.net Sent: Thursday, June 21, 2012 10:19 AM Subject: Re: [Kicad-developers] Clearance and rounding in kicad-nano I think we all know that freerouter is much better on this, but I think Lorenzo is asking about basic routing capabilities (like not letting us put tracks breaking clearance rules...) at least we should find the way to keep the basic routing capabilities in pcbnew. Having awesome ones (like freerouter) might need funding or miracles... I agree on that. We have a big dependency to a closed software because of freerouter. If Alfon shuts it down at any time, for any reason, and we have lost our basic skills... then you couldn't route. My 2 cents, 2012/6/21 Dick Hollenbeck d...@softplc.com On 06/20/2012 05:01 AM, Lorenzo Marcantonio wrote: I've got these issues when routing a board. Let's say I'm doing a 0,2/0,2mm routing (i.e. 0,2mm of track separated by 0,2mm of clearance). Which is huge by today standard (in mil it's about an 8/8) but the numbers are easy :D Grid is set to 0,05 as for IPC recommendations (also it's a good general purpose grid). Now, the issue is that you *can't* put the tracks at exactly the specified distance (DRC during track drawing rejects it). In fact, the 'stick to wall' feature (no better name for it, when you 'push' the track against another one) gives the following results: Po 0 30.8 15.9 30.8 20.1 0.2 -1 De 15 0 1 4FE19D7F 0 Po 0 31.22 16.05 31.22 20.12 0.2 -1 De 15 0 2 4FE19DC4 0 Yes, that's 2 nanometers away :D these 2 nm anyway break the 'grid beauty' and are unconvenient anyway (you can't route adjacent tracks without the stick to wall feature). What's the plan for this? I suppose I could set the clearance to, say, 0,18... I mean, there should be a better solution, IMHO I use freerouter to route ALL boards that I develop in Pcbnew. For most boards, I use the manual routing within freerouter, which provides push and shove routing. You can also auto-route a single net at a time within freerouter. Here are the most common conceptual mistakes folks have with routing in Pcbnew and freerouting: a) They assume that freerouter is only an auto-router. b) They do not recognize that freerouter has a great push and shove manual routing capability. c) They do not realize that auto-routing can be done on a subset of the board, and manually on the balance. That subset can be zero. d) They assume that freerouter's capability can easily be duplicated, as if Alfon's 10 man-years of development on the thing is something you do, or ask for merely by posting an email to a free project's mailing list. e) That Pcbnew's routing capability is even one 1/10th as good as freerouting's is. I for one, have NO plans to work on Pcbnew's routing capability without funding. If someone can duplicate what Alfons has done in less than 10 man years, for free, then they are giving away valuable time for which some commercial software company would likely pay a good salary to and for. Talent x time = $ Them's the facts. ___ 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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] It's me or pcbnew sucks a lot of cpu?
Just starting results in 0% CPU loading in my case: Build: (2012-06-02 BZR 3592)-stable wxWidgets 2.8.12 Debian release 6.0.5 (squeeze) Kernel Linux 2.6.32-5-amd64 From: Lorenzo Marcantonio l.marcanto...@logossrl.com To: Kicad Developers kicad-developers@lists.launchpad.net Sent: Wednesday, June 13, 2012 1:44 PM Subject: [Kicad-developers] It's me or pcbnew sucks a lot of cpu? Just starting it put's the load up to 100%... that's not good. Is it happening only to me? Anyone ever did a profiling build? -- Lorenzo Marcantonio Logos Srl ___ 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] Fwd: Membership request
I had been granted a write permission to Kicad SVN repository since 2008. At the same time I was involved to pcad2kicad project and added polygons support. pcad2kicad is mostly written in Delphi. It was agreed to rewrite pcad2kicad in C++ in order to integrate it into Kicad and provide the opportunity for more people to be involved in the developing process. Unfortunately, since that time both the former of pcad2kicad and I had had no spare time to continue the development. But now I have just started to develop a new device and I want to use Kicad for that. So I need to convert some libraries into Kicad and decided to resume my plans with pcad2kicad converter. That is why I created the pcad2kicad branch that you noticed some days ago. P.S. Several weeks ago I tried to find Kicad project in old locations, firstly on the sourceforge.net Wiki. But there are some issues. As I understood, Kicad developing group was removed from Yahoo and I do not know why. I think I missed much. And now I see that Kicad is on Launchpad and Bazaar repo is used where I have not got the write permission. So there are many surprises to me. From: Miguel Angel Ajo Pelayo miguelan...@nbee.es To: Dick Hollenbeck d...@softplc.com Cc: KiCad Developers kicad-developers@lists.launchpad.net Sent: Monday, June 11, 2012 10:05 AM Subject: Re: [Kicad-developers] Fwd: Membership request I've been thinking about to ask for the same thing for a long time already , but didn't feel ready yet ;-) Alexander, didn't see your p-cad plugin branch, how is it going, it's a good thing :-) 2012/6/10 Dick Hollenbeck d...@softplc.com Hi. Would you add me to the team? -- This message was sent from Launchpad by Alexander Lunev (https://launchpad.net/~al-lunev) using the Contact this team's admins link on the kicad-testing-committers team page (https://launchpad.net/~kicad-testing-committers). For more information see https://help.launchpad.net/YourAccount/ContactingPeople ___ 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 -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo ___ 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
