Re: [Kicad-developers] exploiting human readability
> Attached is the result of the first 1/2 hour of work. Sorry I did not
> get more time this weekend on it.
>
> More over the next several days.
>
More now.
Almost big enough now to test against doxygen.
Dick
// Author Dick Hollenbeck
typedef std::string STRING;
typedef std::vector< STRING > STRINGS;
const STRING StrEmpty = "";
/**
* Class LPID (aka GUID)
* is a Logical Part ID and consists of various portions much like a URI. It
* relies heavily on a logical library name to hide where actual physical library
* sources reside. Its static functions serve as managers of the library table to
* map logical library names to actual library sources.
*
* Example LPID string:
* "kicad:passives/R".
*
*
* "kicad" is the logical library name.
* "passives" is the category.
* "passives/R" is the partname.
*
*
* This class owns the library table, which is like fstab in concept and maps logical
* library name to library URI, type, and password. It has the following columns:
*
* Logical Library Name
* Library Type
* Library URI
* Password
*
*
* For now, the Library Type can be one of:
*
* "dir"
* "schematic" i.e. a parts list
* "subversion"
* "bazaar"
* "http"
*
* For now, the Library URI types needed to support the various types can be one of:
*
* "file://C:/mylib"
* "svn://kicad.org/partlib/trunk"
* "http://kicad.org/partlib";
*
* The library table is built up from several sources, and is a contatonation
* of those sources.
*/
class LPID // aka GUID
{
/**
* Constructor LPID
* takes aLPID string and parses it. A typical LPID string uses a logical
* library name followed by a part name.
* e.g.: "kicad:passives/R".
*/
LPID( const STRING& aLPID ) throw( PARSE_ERROR );
/**
* Function GetLogLib
* returns the logical library portion of a LPID.
*/
STRING GetLogLib();
/**
* Function GetCategory
* returns the category of this part id, "passives" in the example at the
* top of the class description.
*/
STRING GetCategory();
//--
/**
* Function GetLibraryURI
* returns the full library path from a logical library name.
*/
static STRING GetLibraryURI( const STRING& aLogicalLibraryName );
/**
* Function GetLibraryType
* returns the type of a logical library.
*/
static STRING GetLibraryType( const STRING& aLogicalLibraryName );
/**
* Function GetLogLibraries
* returns the logical library names, all of them.
*/
static STRINGS GetLogLibraries();
};
class LIBRARY_SOURCE
{
public:
/*
NRVO described:
http://msdn.microsoft.com/en-us/library/ms364057%28VS.80%29.aspx
Even with NRVO provided by the compilers, I don't see it being as lean as
having the LIBARY keep an expanded member STRING for the aResult value. So I
am heading towards passing STRING* aResult and STRINGS* aResults. Rather
than returning a STRING.
*/
virtual STRING GetSourceType();
virtual void ReadPart( STRING* aResult, const STRING& aName, const STRING& aRev=StrEmpty ) throw( IOError ) = 0;
virtual void ReadParts( STRINGS* aResults, const STRINGS& aNames ) throw( IOError ) = 0;
virtual void GetCategories( STRINGS* aResults ) throw( IOError ) = 0;
virtual void GetCategoricalParts( STRINGS* aResults, const STRING& aCategory ) throw( IOError ) = 0;
virtual void GetRevisions( STRINGS* aResults, const STRING& aName ) throw( IOError ) = 0;
virtual void FindParts( STRINGS* aResults, const STRING& aQuery ) throw( IOError ) = 0;
protected:
STRING sourceType;
STRING sourceURI;
};
class LIBRARY_SINK
{
public:
virtual void WritePart( const STRING& aName, const STRING& aSExpression ) throw ( IOERROR ) = 0;
protected:
STRING sinkType;
STRING sinkURI;
};
class LIBRARYS
{
static LIBRARY* MakeLIBRARY( const STRING& aLogicalLibrary ) throw( IOError );
static LIBRARY* FindOpened( const STRING& aLogicalLibrary );
~LIBRARIES();
private:
/// collection of LIBRARYs, searchable by logical name.
std::map< STRING, LIBRARY* >libraries; // owns the LIBRARYs.
};
/**
* Class LIBRARY
* is a cache of parts.
*/
class LIBRARY
{
public:
/**
* Constructor LIBRARY
*
* @param aLogicalLibrary is the name of a well know logical library, and is
* known because it already exists in the library table.
*
* @param aLibrarySource is an open LIBRARY_SOURCE whose ownership is
* given over to this LIBRARY.
*
* @param aLibrarySink is an ope
Re: [Kicad-developers] Improving usability of KiCad
On 10/11/2010 01:29 PM, Brian F. G. Bidulock wrote: > Alex, > > On Mon, 11 Oct 2010, Alex G wrote: > >> Please guys, stop arguing. I agree with changing the base unit system to >> metric, and I have already voiced that opinion. No one tried to chop my >> throat. If it makes sense to switch to metric why not do it? >> >> The real question is wether it makes sense. >> > I have several 1000-ball BGAs on a metric pitch. Every other ball is off > its position by part of 1/1th of an inch. No problem? Well when > pulling dogbones for BGA breakout, I wind up with about 1000 0.1mil segments > connecting the imperial gridded vias to the imperial gridded balls. So > I tried unlocking the 45-degree tracks pulling slightly off 45-degrees so > that there were no 0.1mil segments. Instead I got 1000 DRC errors (yeah, > its tight in there), and a thousand 0.0mil segments. Then there is the > performance problems associated with drawing thousands of 0.1mil or 0.0mil > traces. Hard locking to a 10 nanometer minimum grid would remove all these > problems. Any time pads, pins or lands are on a metric pitch, the same > problems arise. > > The maximum precision allowed by RS-274X is 6.6 for metric, so it makes > sense to use 1 nanometer as the internal unit. > Brian, This is something I would not oppose. Its clear we may need finer granularity on the *internal* units. In any case, this rounding problem is intolerable. The internal units are the grand unifier between the two or more types of real world units. We should also support more than one type of real world units, by mentioning them in the part or footprint. Internally however, I'd like to work with the *internal* units. One poster said something that I still wonder about, and that C++ cannot reliably multiple and divide by 2.54 and do a round trip conversion using the current internal unit granularity. It is mind boggling that 2.54 and using a C++ double does not allow this to happen. I don't have time to test it, but I am wondering about it. Is this a problem with 64 IEEE float, or that we simply do not have enough resolution in our internal units? 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] make uninstall: no rule?
On 10/08/2010 05:07 AM, Fabio Varesano wrote: > Attached you find a patch (created with bzr send) which add CMake > rules to create a uninstall make rule. > > I did it following the CMake wiki you linked and it should work if one > compile from the build directory (building all kicad). > > You can test it running the following commands from the kicad source > tree root: > mkdir build > cd build > cmake ../ > make > (using root) make install > (using root) make uninstall > > Probably a similar approach shuold be added to all various > subprograms so that one could uninstall eg pcbnew only. I'm sure on > how to proceed with this. > : > Fabio Varesano > Committed in testing's rev 2535. 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] Improving usability of KiCad
>> I have several 1000-ball BGAs on a metric pitch. Every other ball is off >> its position by part of 1/1th of an inch. No problem? Well when >> pulling dogbones for BGA breakout, I wind up with about 1000 0.1mil segments >> connecting the imperial gridded vias to the imperial gridded balls. So >> I tried unlocking the 45-degree tracks pulling slightly off 45-degrees so >> that there were no 0.1mil segments. Instead I got 1000 DRC errors (yeah, >> its tight in there), and a thousand 0.0mil segments. Then there is the >> performance problems associated with drawing thousands of 0.1mil or 0.0mil >> traces. Hard locking to a 10 nanometer minimum grid would remove all these >> problems. Any time pads, pins or lands are on a metric pitch, the same >> problems arise. >> >> > Ouch!!! > > >> The maximum precision allowed by RS-274X is 6.6 for metric, so it makes >> sense to use 1 nanometer as the internal unit. >> >> > I agree. i don't understand why Dick is so hard set against metric. > Maybe if you uploaded your branch/fork to launchpad, and enough people > started throwing their firewood on that fire, he might turn softer. > > Alex > Alex, I said nothing about metric. PCBNEW -- I'd like to see support for both metric and imperial (which we mostly have), along with the 3rd notion of integer based internal units. The problem we have now is that the granularity of the internal unit is not fine enough to avoid round trip conversion errors. The finer we go, the more memory the internal "cell" based autorouter (in PCBNEW) needs, and the longer it will take. The change in memory and speed will likely be related to the square in the granularity change. So if you increase the granularity by 100, then you'll need 10,000 times as much memory and time to run it. (So maybe you decide at that point to simply toss it out and use freerouter.) If you take the autorouter off the table, then the question becomes, "is there a downside to having granularity that is finer than you need?" This is a question, not a suggestion. -- Here is a posting which claims to have found the greatest common denominator, GCD, for a new internal unit: https://lists.launchpad.net/kicad-developers/msg03757.html Here is another opinion: https://lists.launchpad.net/kicad-developers/msg03729.html Here is the root of the thread: https://lists.launchpad.net/kicad-developers/msg03720.html Until we revise the file format for PCBNEW, along with a comprehensive migration plan, including a *.brd board converter, the best we can do is plan and summarize, and schedule for later completion. A summarizing paragraph could be formulated on this mailing list and then copied to a blueprint after it is agreed to by a majority, inclusive of someone willing to do the work. That's about all I can think to say about it for now. 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] launchpad branding images
On 10/12/2010 06:41 AM, Fabio Varesano wrote: > I would be happy to do that! Should I use artwork/kicad.svg as > starting point? > > FV > Sounds good, no sense swimming upstream. 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
Re: [Kicad-developers] launchpad branding images
On 10/12/2010 08:07 AM, Fabio Varesano wrote: > There you go. > > FV > You da man! Go see your work at launchpad.net > On 10/12/2010 02:12 PM, Dick Hollenbeck wrote: > >> On 10/12/2010 06:41 AM, Fabio Varesano wrote: >> >>> I would be happy to do that! Should I use artwork/kicad.svg as >>> starting point? >>> >>> FV >>> ___ 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] Improving usability of KiCad
O > I wonder if it occurred to others - if the inch had been defined as 25.6 > instead of 25.4/mm this > problem would have been quite different. I thought the inch was defined first. > I do think the inch will die out someday. That's what they said in here in the USA in the 1960's. And then Dr. Spock came along and the world got soft, teachers got a break, kids got a break. In the 1960's I remember there being a commitment to learn metric, then that commitment went away, because it meant, ahem, work and study and teaching. Not just for kids in school but also for adults out of school. It might have been a nice thing to do with the Y2K initiative. You know, declare the inch dead. The problem obviously is the machine tools, tools, etc. But if we simply started measuring everything in metric, the 2.54 that we would see everywhere would eventually get tiresome and the machines would eventually get made in metric. 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] Improving usability of KiCad
On 10/13/2010 09:48 AM, Marco Serantoni wrote: > > On Oct 13, 2010, at 8:17 AM, Dick Hollenbeck wrote: > >> >>> I wonder if it occurred to others - if the inch had been defined as >>> 25.6 instead of 25.4/mm this >>> problem would have been quite different. >> >> I thought the inch was defined first. >> >>> I do think the inch will die out someday. >> >> That's what they said in here in the USA in the 1960's. And then Dr. >> Spock came along and the world got soft, teachers got a break, kids got >> a break. In the 1960's I remember there being a commitment to learn >> metric, then that commitment went away, because it meant, ahem, work and >> study and teaching. Not just for kids in school but also for adults out >> of school. > > Dick, we doesn't want that US will change its metric system, nor begin > a lesson of metrology. > Scientific international system is MKS, wxDC has also calls that > returns millimeters, the greatest part of the world population uses a > metric system, ISO 31 says the same, don't you find those be good > reasons to switch the internal metric system to a metric one ? > > Mr Spock could say in this occasion: the many outweigh the needs of > the few. > > -- > Marco No idea what you are talking about Marco. Your reply does not match my posting. You have a misunderstanding about what I said. My posting was in English, but that seems not to have been good enough. 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] Improving usability of KiCad
On 10/13/2010 10:01 AM, Alex G wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/13/2010 05:48 PM, Marco Serantoni wrote: > >> Dick, we doesn't want that US will change its metric system, nor begin a >> lesson of metrology. >> Scientific international system is MKS, wxDC has also calls that returns >> millimeters, the greatest part of the world population uses a metric >> system, ISO 31 says the same, don't you find those be good reasons to >> switch the internal metric system to a metric one ? >> >> > Marco, > > We already agreed earlier in this thread to make a summarize the > (re)implementation of the internal unit system. My understanding was > that once enough developers agree to it, we can put it as a blueprint > and those interested (myself included) can start work. > > Alex > Jean-Pierre has not objected. There is probably some considerations about extending the range of the zoom that come with this, and how the UI is to handle that. Will the zoom menu get too big, etc. And some other issues that still need to be discussed about the actual migration, what that means in terms of saving a board, or a footprint (save as old, save as new, or either). Where we designate what the units are in those saves. I think it prudent to adopt your paragraph as the opening paragraph at this point. Then we should add a couple of more before the coding begins. Brian says he has already done some of this work. There is no harm in defining what is needed, and then going to see what he has done. If we do it the other way around, we might miss something. Alex, go ahead and put your first paragraph out there if you don't mind. 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] Improving usability of KiCad
On 10/13/2010 10:47 AM, Alex G wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/13/2010 06:40 PM, Dick Hollenbeck wrote: > >> Jean-Pierre has not objected. There is probably some considerations >> about extending the range of the zoom that come with this, and how the >> UI is to handle that. Will the zoom menu get too big, etc. And some >> other issues that still need to be discussed about the actual migration, >> what that means in terms of saving a board, or a footprint (save as old, >> save as new, or either). Where we designate what the units are in those >> saves. >> >> >> I think it prudent to adopt your paragraph as the opening paragraph at >> this point. Then we should add a couple of more before the coding >> begins. Brian says he has already done some of this work. There is no >> harm in defining what is needed, and then going to see what he has >> done. If we do it the other way around, we might miss something. >> >> Alex, go ahead and put your first paragraph out there if you don't mind. >> >> > Done. Here's the blueprint (I hope this is what I was supposed to do). > https://blueprints.launchpad.net/kicad/+spec/unit-system > > Alex > Thanks Alex. Maybe Brian B can coach you through something resembling a discussion plan and a patch. Anything involving a file format change is worth being careful about, we have customers you know. :) This is why I am trying to get all the issues understood up front, no hurry on this. They don't like to have their designs broken. 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] Improving usability of KiCad
On 10/13/2010 12:59 PM, Wayne Stambaugh wrote: > On 10/13/2010 10:48 AM, Marco Serantoni wrote: > >> On Oct 13, 2010, at 8:17 AM, Dick Hollenbeck wrote: >> >> >>> >>>> I wonder if it occurred to others - if the inch had been defined as 25.6 >>>> instead of 25.4/mm this >>>> problem would have been quite different. >>>> >>> I thought the inch was defined first. >>> >>> >>>> I do think the inch will die out someday. >>>> >>> That's what they said in here in the USA in the 1960's. And then Dr. >>> Spock came along and the world got soft, teachers got a break, kids got >>> a break. In the 1960's I remember there being a commitment to learn >>> metric, then that commitment went away, because it meant, ahem, work and >>> study and teaching. Not just for kids in school but also for adults out >>> of school. >>> >> Dick, we doesn't want that US will change its metric system, nor begin a >> lesson >> of metrology. >> Scientific international system is MKS, wxDC has also calls that returns >> millimeters, the greatest part of the world population uses a metric system, >> ISO 31 says the same, don't you find those be good reasons to switch the >> internal metric system to a metric one ? >> >> Mr Spock could say in this occasion: the many outweigh the needs of the few. >> > Marco, > > Wrong Spock! Dr. Spock was one of the first child psychologists to write a > parenting book which unfortunately a lot of parents bought into. He naively > believed that you could raise healthy well adjusted adults by coddling their > egos as children by telling them how wonderful they were even when they > weren't. This had the adverse effect of creating several generations of > adults > who feel entitled to everything without doing anything. These are the adults > who are always complaining about how unfair everything is. This parenting > method was the antithesis of the old school parenting method of corporal > punishment (spanking) and demanding that children tow the line. Thankfully, > my > parents didn't subscribe to the Dr. Spock method of child rearing even though > he published his book around the time I was born. I'll get off my soapbox > now. > No reason to. Wayne for president! You should at least start your own newspaper or blog, PLEASE! > 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] [PATCH] expat dependency for cmake
FYI, Kicad does not use expat directly. wxWidgets does. wxWidgets includes expat in its source tree. So one can argue that this is a discussion for the wxWidgets build environment, and if it is built properly, then Kicad can simply use wxWidgets, which should be responsible for the libraries that it needs. Maybe an equally valid solution is to submit a patch to the wxWidgets team, or to your distro team, or whatever. It may not be the best solution, but before I identify the best solution, I usually try and find more than one. 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] [PATCH] expat dependency for cmake
On 10/15/2010 09:26 AM, Martijn Kuipers wrote: > On Oct 15, 2010, at 15:04 PM, Dick Hollenbeck wrote: > > >> FYI, >> >> Kicad does not use expat directly. wxWidgets does. wxWidgets includes >> expat in its source tree. >> > Well wxWidgets includes wxexpat in its source tree, not exactly expat per se. > > >> So one can argue that this is a discussion for the wxWidgets build >> environment, and if it is built properly, then Kicad can simply use >> wxWidgets, which should be responsible for the libraries that it needs. >> > I wondered about that too. In order to compile wx I use the > --enable-monolithic option, but then it does not make builtin support for > zlib, expat and perhaps some others (at least on OSX). Do you consider this a > wxWidgets error? > > Another option is to make a multi-lib build and make kicad responsible for > taking in all libs, but that requires more cmake surgery. > > >> Maybe an equally valid solution is to submit a patch to the wxWidgets >> team, or to your distro team, or whatever. >> > I just wanted Kicad to tell me beforehand (before building) that my > dependencies are not in order. I don't think Kicad should tell me whom I > should blaim for this. > > >> It may not be the best solution, but before I identify the best >> solution, I usually try and find more than one. >> > I weighted the odds and thought that adding the expat one is reasonable, but > if you prefer a multilib build then I will prepare the OR and begin the > surgary. > If I were to participate in appraising the relative merits of alternative solutions, I would think that anything that is OSX specific should be pushed back to OSX folks, anything that is wxWidgets specific should be pushed back to wxWidgets, or maintained as a separate patch to wxWidgets, etc. If we work long enough on the cmake scripts, eventually we will not be able to read them. But I am not participating in this. I don't have the pain you do. I am using Ubuntu Lucid, without issue. Even though I was instrumental in crafting the first CMake buid of Kicad on Windows, I haven't has windows on my machine for at least 4 years, and stopped using it about 9 years ago. So I am not currently qualified to make the judgement. But I just suggest that weight be given to putting blame where blame belongs. Pros and cons are weighed according to their importance, and others will have different weights. Expat is not a fixture in Kicad. We might decide to switch to another XML library in the future. 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] [PATCH] expat dependency for cmake
On 10/15/2010 09:26 AM, Martijn Kuipers wrote: > On Oct 15, 2010, at 15:04 PM, Dick Hollenbeck wrote: > > >> FYI, >> >> Kicad does not use expat directly. wxWidgets does. wxWidgets includes >> expat in its source tree. >> > Well wxWidgets includes wxexpat in its source tree, not exactly expat per se. > It is a nested checkout, I don't have time to dispute this with fact. But let's say I question your statement. 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] [PATCH] expat dependency for cmake
On 10/16/2010 02:20 AM, Martijn Kuipers wrote: > On Oct 15, 2010, at 15:50 PM, Dick Hollenbeck wrote: > > >> On 10/15/2010 09:26 AM, Martijn Kuipers wrote: >> >>> On Oct 15, 2010, at 15:04 PM, Dick Hollenbeck wrote: >>> >>> >>> >>>> FYI, >>>> >>>> Kicad does not use expat directly. wxWidgets does. wxWidgets includes >>>> expat in its source tree. >>>> >>>> >>> Well wxWidgets includes wxexpat in its source tree, not exactly expat per >>> se. >>> >>> >>> >>>> So one can argue that this is a discussion for the wxWidgets build >>>> environment, and if it is built properly, then Kicad can simply use >>>> wxWidgets, which should be responsible for the libraries that it needs. >>>> >>>> >>> I wondered about that too. In order to compile wx I use the >>> --enable-monolithic option, but then it does not make builtin support for >>> zlib, expat and perhaps some others (at least on OSX). Do you consider this >>> a wxWidgets error? >>> >>> Another option is to make a multi-lib build and make kicad responsible for >>> taking in all libs, but that requires more cmake surgery. >>> >>> >>> >>>> Maybe an equally valid solution is to submit a patch to the wxWidgets >>>> team, or to your distro team, or whatever. >>>> >>>> >>> I just wanted Kicad to tell me beforehand (before building) that my >>> dependencies are not in order. I don't think Kicad should tell me whom I >>> should blaim for this. >>> >>> >>> >>>> It may not be the best solution, but before I identify the best >>>> solution, I usually try and find more than one. >>>> >>>> >>> I weighted the odds and thought that adding the expat one is reasonable, >>> but if you prefer a multilib build then I will prepare the OR and begin the >>> surgary. >>> >>> >> If I were to participate in appraising the relative merits of >> alternative solutions, I would think that anything that is OSX specific >> should be pushed back to OSX folks, anything that is wxWidgets specific >> should be pushed back to wxWidgets, or maintained as a separate patch to >> wxWidgets, etc. >> > Great. If this works we would not need autoconf or cmake at all, just simple > makefiles. > Hmm, perhaps we should program for the real world and accepts that this is > not going to happen any time soon. > > >> If we work long enough on the cmake scripts, eventually we will not be >> able to read them. >> > That's why you can add comments to them too. > > >> But I am not participating in this. I don't have the pain you do. I am >> using Ubuntu Lucid, without issue. >> > So, as long as it works on Ubuntu Lucid it is an upstream bug? > > >> Even though I was instrumental in crafting the first CMake buid of Kicad >> on Windows, I haven't has windows on my machine for at least 4 years, >> and stopped using it about 9 years ago. So I am not currently qualified >> to make the judgement. >> > Neither am I. I don't use windows enough to understand all its intrigues. > > >> But I just suggest that weight be given to putting blame where blame >> belongs. Pros and cons are weighed according to their importance, and >> others will have different weights. >> >> Expat is not a fixture in Kicad. We might decide to switch to another >> XML library in the future. >> > Open source has no fixtures, that is why it is open source. That doesn't mean > that we should not try to get it to work on all supported platforms. > > I am not even sure this is a wx problem. Should wx-config add the -lexpat > flag if it uses the system-lib? > Even so, it does not now, and we can detect that and solve it now. > wxWidgets depends on expat. Kicad does not depend on expat. Just these statements alone suggest the problem is in wxWidgets. There are two ways that wxWidgets depends on expat: 1) wxXml class depends on expat. 2) xrc depends on wxXml which depends on expat My current theory is this: wxWidgets folks have probably gotten their build system fairly robust for users of 2), i.e. xrc. For those that are only using 1), like Kicad, then they still have a hole or two. When we say "they", Perhaps a test should be done to depend on the xrc support, even though we don't use it. That might be another way to consider plugging this hole. The provider of wxWidgets is definitely a factor also to consider also, where does it come from? If it comes from the distro repo, then there is a package maintainer in this picture also, else 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] exploiting human readability
On 10/08/2010 07:41 AM, Wayne Stambaugh wrote:
> On 10/7/2010 6:26 PM, Dick Hollenbeck wrote:
>
>>
>>> (part REFDES is PLID
>>> (at X Y)
>>> (rot 0) # make this optional, defaulting to zero
>>> )
>>>
>>>
>>
>> Schematic component instantiation:
>> -
>>
>> I don't know that "part" is best, and there may be a better name.
>>
>> But what I see from this, unless there are holes in the concept, is that
>> there need be *NO location information* in what we have been calling the
>> component, nor any rotation information.
>>
>> That can be introduced in the part C++ PART class for the very first
>> time. The graphics primitives in the component have their coordinates,
>> but those coordinates are relative to the component's origin, not any
>> thing beyond that.
>>
>>
>> The component is located and rotated [and mirrored] when it is
>> instantiated within a part.
>>
This class PART is now backwards, see text below. Class COMPONENT now
points to a PART, and is imply an instantiation of a PART.
>>
>> class PART
>> {
>> COMPONENT* component// points into the parts list
>>
>> POINT pos;
>>
>> wxString reference;
>>
>> int angle;
>> }
>>
>>
>> Something like that. Maybe also mirroring support at the PART level.
>> The get bounding box function delegates to the COMPONENT, and offsets
>> and rotates the result of that box to the region on screen.
>>
>> Are part and component properly named?
>>
> I can't really think of a better one. Generally speaking, you think in terms
> of adding components to your schematic not parts. At the user level you
> should
> use the term component but internally you could differentiate by defining
> components similar to the way we do now which is LIB_COMPONENT ( your
> COMPONENT) and SCH_COMPONENT ( your PART ). But I'm not sure this is any
> better.
>
> Wayne
>
Well as you may have seen, I started down the path of PART for what
lives in the LIBRARY or PARTS_LIST, and COMPONENT for what lives in the
schematic. I think this is consistent with the generic XML export, but
perhaps a swap from what has been discussed on this list recently. (But
after all, how can you not put a PART in a PARTS_LIST?)
My next commit will have quite a bit more in it, class PARTS_LIST, class
COMPONENT (mostly as a place holder for you) along with an architecture
diagram, and doxygen docs.
The PARTS_LIST is a difficult concept to grasp from words alone,
especially the difference between its role within its containing
schematic, vs. its role for another schematic.
The diagram and text in my next commit will clarify this, and be spit
out as a cohesive Doxygen *.html file set.
There should be enough at that point to mostly capture the ideas, and to
start coding. I keep hammering on the idea that with the new design,
libraries can actually read only entities. Why share something that is
not re-usable as is? This is a departure from the way some folks are
currently thinking, no doubt. But the PARTS_LIST comes to the rescue as
the modification arena.
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] (no subject)
___ 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] Did you change something in the drawing code?
On 10/18/2010 01:29 AM, Lorenzo Marcantonio wrote: > BTW there is a way in bzr to know what was the 'parent' > revision number in a merge? > $ bzr qlog Seems to be the best way to view almost anything. 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] Interesting idea to make money with open-source
On 10/14/2010 11:50 PM, Michael Heidinger wrote: > Hi, > > i find this idea great. I really like that. There are some features to > realize I would pay for it; but I'm afraid this can't be enought to live > from this little money (lets say up to 100 usd for a "big" feature). > > My idea is the following: > 1. Step: Feature proposal: A user proposes a new feature. > 2. If you consider it as too special, e.g. someone can say "I will do it > for the amount x usd as it is very speacial (but the price must be > fair!) in x days". Now its awailable in a kind of store, where you can > buy percentages of the feature. Of course 1 person can buy 100%! The > money is transfered to an account of trust. > 3. If 100% of the amount is reached the developer starts developing. > After the user is satisfied the account of trust transfers the money. > 4. Now the feature is awailable for everyone. In the corresponding > source code is marked "sponsored by user x programmed by user y" > > I really like this idea, as I am not very experienced in software > programming and I sometimes would really need some improvements for a > faster more efficent pcb design. > Keep in mind: Some guys also use that program to make money, so why > shouldn't also you, the development team, profit from it? > > What I would be interested in: Are the developpers interested? It only takes one. Some feature requests sit for years, folks wonder when they're going to get done. Features normally only get done when the guy coding it has the same problem, so in that case it has been referred to as scratching your own itch. Beyond this (intersection of my problem and your problem), the open source model breaks down. I think there are already sites that are intended to conduct business along these lines, and are targeted for open source projects. It should be no mystery that qualified folks won't work for free. The major open source projects have corporate sponsors, so even those guys are not working for free. Dick > Taking > money also means to statisfy the wishes of the customer and that means a > minimized freedom in programming. > > See you > Michael > ___ 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] expat dependency for cmake
On 10/17/2010 04:06 PM, Martijn Kuipers wrote: > On Oct 17, 2010, at 22:02 PM, Wayne Stambaugh wrote: > > >> On 10/16/2010 2:52 PM, Martijn Kuipers wrote: >> >>> >>> There are two ways that wxWidgets depends on expat: 1) wxXml class depends on expat. 2) xrc depends on wxXml which depends on expat My current theory is this: wxWidgets folks have probably gotten their build system fairly robust for users of 2), i.e. xrc. For those that are only using 1), like Kicad, then they still have a hole or two. When we say "they", Perhaps a test should be done to depend on the xrc support, even though we don't use it. That might be another way to consider plugging this hole. The provider of wxWidgets is definitely a factor also to consider also, where does it come from? If it comes from the distro repo, then there is a package maintainer in this picture also, else not. Dick >>> Thanks Dick and Wayne for your clear explanation. Though even if it is a >>> wx problem, should we not plug the hole while we await a fix from upstream? >>> >> Martin, >> >> On my home machine with wxWidgets build as individual static libraries >> using expat included with wxWidgets, wx-config --libs xml yields the >> following output: >> >> -L/mingw/lib -mthreads /mingw/lib/libwx_baseud_xml-2.8.a >> /mingw/lib/libwx_baseud-2.8.a -lwxregexud-2.8 -lwxexpatd-2.8 -lz >> -lrpcrt4 -luuid -lodbc32 -lole32 -loleaut32 -lwinspool -lwinmm -lshell32 >> -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 >> >> It appears that in this case, wx-config is returning the correct expat >> library to link against. I'll check my machine a work tomorrow. I'm >> pretty sure I build wxWidgets using the expat library I build separately >> and see if it includes -lexpat instead of -lwxexpatd-2.8. >> >> Wayne >> > Thanks Wayne, > > I am on OSX if that makes a difference. Marco has already created a > bug-report at wx, so let's see what they do. > > /Martijn > CMake has this command: include( .cmake ) It is an inter-project communication mechanism that I have used in house here, for two projects that are both based on CMake. I think we'd award the "man of the year award" to the guy who could spend three hours creating a full CMakeLists.txt system for wxWidgets, and sell that project on using the CMake tool (maybe not in that order). The persuasive argument would go along the lines of "KDE uses CMake, so", "Kicad is one of the largest multi-platform customers of wxWidgets, and we like CMake and don't like the fact that wx-config sometimes falls down..." That new wxWidgets CMake build system then could export() the .cmake into Kicad's build system. This would solve all the problems on all the platforms as far as I am concerned. 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] Events inside kicad
On 10/26/2010 01:50 PM, Marco Serantoni wrote: > In those days i was thinking about to add an internal event generation for > some kicad classes. > Adding internal events at wxAUIManager could be a good start to implement > "external frames" and utilities (plugins) , making possible plug-in new > functionalities and probably reorganizing some parts of code > > I've already something ready, if nobody has something against it i wish > commit the first tranche of the implementation on pcbnew. > If it is as disruptive as you say, can we see a patch and have a short chat about it before you commit? It would be good for Jean-Pierre and Wayne to get a look. I don't think there is any fundamental objections to improvements though :) 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] Events inside kicad
On 10/26/2010 01:58 PM, Marco Serantoni wrote: > On 26/ott/2010, at 20.54, Dick Hollenbeck wrote: > > >> On 10/26/2010 01:50 PM, Marco Serantoni wrote: >> >>> In those days i was thinking about to add an internal event generation for >>> some kicad classes. >>> Adding internal events at wxAUIManager could be a good start to implement >>> "external frames" and utilities (plugins) , making possible plug-in new >>> functionalities and probably reorganizing some parts of code >>> >>> I've already something ready, if nobody has something against it i wish >>> commit the first tranche of the implementation on pcbnew. >>> >>> >> If it is as disruptive as you say, can we see a patch and have a short >> chat about it before you commit? >> > Indeed, > Here is the patch, let's chat :) > Thanks for your patience, and willingness to accept feedback. We might need to wait a day or two for folks to comment. I know English is not your favorite language, but it would be easier for folks to grasp what you are trying to do with some supporting documentation. It looks like you have something ambitious in mind. Can an inkscape diagram tell the story better than words, using arrows or what 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] Events inside kicad
On 10/27/2010 03:29 AM, Martijn Kuipers wrote: > On Oct 27, 2010, at 1:27 AM, Wayne Stambaugh wrote: > > >> On 10/26/2010 2:58 PM, Marco Serantoni wrote: >> >>> On 26/ott/2010, at 20.54, Dick Hollenbeck wrote: >>> >>> >>>> On 10/26/2010 01:50 PM, Marco Serantoni wrote: >>>> >>>>> In those days i was thinking about to add an internal event generation >>>>> for some kicad classes. >>>>> Adding internal events at wxAUIManager could be a good start to implement >>>>> "external frames" and utilities (plugins) , making possible plug-in new >>>>> functionalities and probably reorganizing some parts of code >>>>> >> Marco, >> >> Before you commit this, I would like to see an example of how you are >> going to handle these events in some type of plug in framework. I'm >> just not seeing where you are going with this. If you are planning on >> handling these events in any of the Kicad application main windows, that >> doesn't make much sense because it was a command event generated by the >> main window that got you to that point in the first place. What does >> make sense to me it to create some custom command events for handling >> things like zoom and grid selection. One of the often overlooked >> features of command events is that they can be used to pass objects and >> data pointers along with the event by using the Set/GetClientObject and >> Set/GetClientData. I'm not rejecting this patch, but I'm concerned that >> this patch will not be fully developed and no plugins that handle these >> events will ever be written which means there is an unnecessary level >> complexity in this code. >> > > Marco could probably explain it better than I can, but from what I understood > his intention is to make Kicad event-based and using message-passing, pretty > much like wx itself. > > A good explanation of this event-based use (for those that do not already > know it) can be found here: > http://docs.wxwidgets.org/trunk/overview_events.html > > I also misunderstood Marco's email in thinking he was proposing a > plugin-framework, but that is not the case. However, having this in Kicad > would make it easier to add a plugin-framework. Eagle seems to have a large > amount of scripts around, so there must be some use for it. Of course, Kicad > is open source so the most wanted plugins could be ported inside Kicad. > > This is just what I understood after a small conversation I had with Marco. > Of course, he can probably explain things a lot better than me, although he > convinced me it was "a good thing", for what it is worth. > > /Martijn > It could be useful and it could solve a problem. It should not be hard to show an example usage, and doing so would ensure we are not providing a solution to a problem that does not exist. If I ask my wife if I can put a 480V 3 phase outlet in our living room, I should not be surprised when she asks me to show her the catalog page showing the electric razor, or popcorn maker, or vacuum cleaner that I expect to plug in there. She likes pictures. Dick >> >>>>> I've already something ready, if nobody has something against it i wish >>>>> commit the first tranche of the implementation on pcbnew. >>>>> >>>>> >>>> If it is as disruptive as you say, can we see a patch and have a short >>>> chat about it before you commit? >>>> >>> Indeed, >>> Here is the patch, let's chat :) >>> >> Your patch has a few issues. The code formatting is incorrect. Please >> see the recently released coding guidelines in the Kicad source tree or >> use uncrustify to correct the formatting. Also, try to avoid the wx >> prefix when naming source code that is not going to be pushed upstream >> to wxWidgets. I think we should leave that to the wxWidget developers. >> I know there are a few other places in where this is used in the Kicad >> source tree but this is one of those minor things that should be cleaned >> up. Thank you for your effort. >> >> Wayne >> >> >>> -- >>> Marco >>> >>> >>> >>> ___ >>> Mailing list: https://launchpad.net/~kicad-developers >>> Post to : kicad-developers@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.la
Re: [Kicad-developers] Silk screen line width behavior.
On 11/09/2010 02:35 PM, Wayne Stambaugh wrote: > I just got DFM failure from my PCB manufacture for silk screen width of 0.001" > for all the silk screen drawings on a board I just laid out. I checked all of > the module silk screen widths and everything is 0.005" or larger. A quick > check of the silk screen layer gerber file revealed the aperture being used > was > indeed 0.001". After some digging around, I found that changing the "Default > pen size" in the plot dialog changed the silk screen line width. Is this the > appropriate behavior? Setting the default line width to 0 did not fall back > to > the line width defined in the module. I would expect my silk screen line > widths to be what I defined them in my module not the default pen size > setting. > At one time, I thought this was the default behavior. Before I file a bug > report, I wanted to make sure I'm not missing something. Anyone else have any > thoughts on this? > > Wayne > Its not perfectly pertinent to your question, but I have found /scripts/setfont.sh to be useful after I have a board ready to plot. I have not stumbled onto your problem before. Maybe something has changed, or I just missed it. >From a UI perspective, I would not prefer to have to set the default width to zero to say, "leave me alone". I would prefer to select a checkbox saying override the line-widths, or 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
[Kicad-developers] sourceforge.net svn repo is emptied
I was able to erase the content of the SVN repo at sourceforge.net. After doing that I disabled it for general use. But as we have learned, disabling it does not prevent someone from reading from it. However, now it will come up empty during a checkout. The package maintainers will now have to dig a little, for understanding, and update their build scripts to use bzr against launchpad.net. 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] sourceforge.net svn repo is emptied
On 11/11/2010 05:34 PM, Martijn Kuipers wrote: > Hi Dick, > > Great. Why not submit a single text-file saying it is hosted now on lp.? > > /Martijn > I tried, not possible. Sourceforge has the repo set as read only. I had to use svnadmin to bash the damn thing. This way we get a built in IQ test applied before any developers come here. Maybe we'll get only the good ones. The ones that cannot figure out how to compile an empty directory we can simply ignore, assume they don't know how to read, and maybe they will go away. Over and out, and I promise to not to participate in any more discussion on this subject. 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] Revision 2604 has broken cvpcb and some random warnings
Committed in 2607. It fixed the warnings for me and I am happy with it. However, I was not seeing the errors reported by Jerry, and Marco it seems you were not either. So I don't know what is up with Jerry's report. 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] [PATCH] Footprint text umbilicals
Marco, Looks pretty good to me. Dick > Hi, > > Here's a proposal for a feature stolen from Eagle (at least). When > moving footprint reference texts around in crowded areas of a board, > it is sometimes difficult to keep track of, e.g., which reference > belongs to which resistor. The situation would be clearer if there was > a line drawn from the reference and other text fields to the parent > footprint origin. That's what the attached patch adds to pcbnew. In > addition it centers the cursor on the field that is being moved when > the move starts. > > marco > > > > ___ > 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] [PATCH] Pcbnew plot output directory
On 11/20/2010 05:08 PM, Marco Mattila wrote: > Hello all, > > This patch adds an output directory field into the plot dialog in > pcbnew and directs gerber/hpgl etc. output into that directory. > There's a browse button that opens a dialog for browsing. If the > directory does not exist, it is created. Tested in linux, not in > windows. Wxwidgets methods are used for file (name) manipulations, so > things are probably ok in windows, too. > > marco > Committed in testing 2625. 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] [PATCH] Footprint text umbilicals
I wasted 15 minutes only to find this was committted in 2618. ___ 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] Footprint text umbilicals
On 11/21/2010 11:24 AM, jean-pierre charras wrote: > Le 21/11/2010 16:03, Dick Hollenbeck a écrit : > >> I wasted 15 minutes only to find this was committted in 2618. >> >> > Sorry, > I sent a mail to kicad dev list after committed this patch, but I believe > this mail was lost. > > Thanks Jean-Pierre, maybe the email went to Marco and not to the list. I think most all of us have made that mistake at least once. :) 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] Test zone filling with Boost::polygon
On 12/01/2010 02:29 AM, jean-pierre charras wrote: > Le 01/12/2010 04:47, Dick Hollenbeck a écrit : > >> Thanks Jean-Pierre. >> >> I changed to polygon fills everywhere with min zone size of 0.006 >> >> Attached are two png images which show the problem with and without pads >> on top. The problem actually might not be with the boost library but >> with the algorithm used to specify the voids for pads. >> >> Compare the two images, and you'll see that simply by turning on pads >> the problems with the zone reside in the region of some low pitch pads. >> >> Dick >> > I found the bug: algo that removes unconnected thermal stubs when using > thermal pads was always running in boost version, and > removed some sub areas in filled zone areas. > boost::polygon is not the culprit, and seems now work fine. > But obviously needs now more tests. > Thanks Jean-Pierre. The boost::polygon build seems to now creat a good copper area in the region which was previously giving us grief. Nice job catching that. Perhaps we have enough confidence now to switch over to boost::polygon as the default choice in the CMakeLists.txt file? This way we can begin to get more boards to exercise that code. At some point we should also probably update the stable branch also. 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] library structure
On 12/03/2010 12:45 AM, Phinitnan Chanasabaeng wrote: > On Sep 23, 2010, at 1:09 AM, Wayne Stambaugh wrote: > > symbol - The graphical and/or electrical representation of a component. > > Think everything between DRAW/ENDDRAW in the current file format. > > > > > field - The default and user defined text values that describe a > > component such as value, reference designator, footprint, etc. > > > > component - The combination of default and user defined fields and a > > > symbol that get imported into a schematic. > > > > library - One or more components along with some meta-data to describe > > the library. > > > > After a long time reading the whole thread, It only took me 2 minutes. > I too agree with this scheme. > > Then, we may create component's files and use some kind database such as > sqlite to store a group of components(meta data) as libraries. > This will let us do all database task such as searching, tagging, etc. > Editing/copy/paste components in a library will also be easier. > > > Tony > In recent weeks there has been a lot of design work done behind the scenes on eeschema and the whole concept of what a library even is. Everything you know about EESCHEMA has potential to change within the next 4 months. The first reveal of the new design will happen within days. Incremental enhancements, enhancement requests, and wish list items, which are based on the current design, are probably wasted time. Feedback is best offered between the time when the new proposed design is revealed and when coding starts, circa 2 weeks. 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] library structure
On 12/04/2010 02:19 AM, Michael Heidinger wrote: > First i want to say that metric is standard in the world. This has a > reason: All unites are logically structured and easyly convertable into > other units of the SI system. Having both will just cause problems and > will be confusing for everybody. So lets do it one time the correct way > and stop unit-mesurement-problem 4ever! Lets fix it on one standard: Metric. > No. Lets remember we are talking about eeschema here, not pcbnew. * pcbnew library redesign is another time, and another effort. * metric schematics are only mildly useful. By this, I assume one would mean grid spacing? Remember schematic parts are not actual footprints. We can support metric schematic parts, but I think aligning to a common grid size will in the end be more useful. What good is it to load a schematic part and have its pins not aligned to a common grid? Again, schematics, not footprints or pcbnew are in discussion here. Much will be learned and pioneered here for EESCHEMA, and then the more demanding PCBNEW library concepts can be handled later. I don't want to get into PCBNEW libraries yet, since any PCBNEW implementation work is thought to be planned later. There will be mandatory additional and more demanding needs for the PCBNEW libraries, and real world engineering units are among them. Wayne is soon revealing a new EESCHEMA part file format document that we worked on together. And soon we are also revealing a C++ class system for a distributed library management system, and the new parts list concept, soon. I just have to make a few more pictures with inkscape, argh, not my familiar tool. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/06/2010 12:37 PM, Marco Mattila wrote:
> === modified file 'common/common_plotGERBER_functions.cpp'
> --- common/common_plotGERBER_functions.cpp2010-11-12 16:36:43 +
> +++ common/common_plotGERBER_functions.cpp2010-12-06 17:43:56 +
> @@ -504,3 +504,11 @@
> set_current_line_width( -1 );
> poly( 5, &polygon[0].x, aTrace_Mode==FILLED ? FILLED_SHAPE : NO_FILL );
> }
> +
> +void GERBER_PLOTTER::SetLayerPolarity( bool aPositive )
> +{
> +if( aPositive )
> +fprintf( output_file, "%%LPD*%%\n" );
> +else
> +fprintf( output_file, "%%LPC*%%\n" );
> +}
>
> === modified file 'include/plot_common.h'
> --- include/plot_common.h 2010-11-12 16:59:16 +
> +++ include/plot_common.h 2010-12-06 17:41:21 +
> @@ -169,6 +169,13 @@
> boolaBold );
> void marker( const wxPoint& position, int diametre, int
> aShapeId );
>
> +/** Function SetLayerPolarity
>
No, see the coding standard for proper formatting of the function header.
> + * sets current Gerber layer polarity to positive or negative
> + * by writing \%LPD*\% or \%LPC*\% to the Gerber file, respectively.
> + * param @aPositive = layer polarity, true for positive
> + */
> +virtual void SetLayerPolarity( bool aPositive ) = 0;
> +
> protected:
> /* These are marker subcomponents */
> void center_square( const wxPoint& position, int diametre,
> FILL_T fill );
> @@ -272,6 +279,8 @@
> virtual void flash_pad_trapez( wxPoint aPadPos, wxPoint aCorners[4],
> int aPadOrient, GRTraceMode aTrace_Mode );
>
> +virtual void SetLayerPolarity( bool aPositive ) {};
> +
> protected:
> void pen_control( int plume );
>
> @@ -321,6 +330,8 @@
> virtual void flash_pad_trapez( wxPoint aPadPos, wxPoint aCorners[4],
> int aPadOrient, GRTraceMode aTrace_Mode );
>
> +virtual void SetLayerPolarity( bool aPositive ) {};
> +
> protected:
> double plot_scale_adjX, plot_scale_adjY;
> };
> @@ -379,6 +390,8 @@
> virtual voidflash_pad_trapez( wxPoint aPadPos,
> wxPoint aCorners[4],
>int aPadOrient,
> GRTraceMode aTrace_Mode );
>
> +virtual voidSetLayerPolarity( bool aPositive );
> +
> protected:
> voidselect_aperture( const wxSize&
> size,
> APERTURE::Aperture_Type
> type );
> @@ -439,6 +452,8 @@
> virtual void flash_pad_trapez( wxPoint aPadPos, wxPoint aCorners[4],
> int aPadOrient, GRTraceMode aTrace_Mode );
>
> +virtual void SetLayerPolarity( bool aPositive ) {};
> +
> protected:
> int current_color;
> };
>
___
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] Option to subtract soldermask from silkscreen in gerber output
Hi, > Board manufacturers typically do not print silkscreen on areas without > soldermask. Nevertheless, it would be nice to have proper gerbers to > begin with, i.e., gerbers with no silkscreen in soldermaskless areas. > Of course, most of the problem can be taken care of by drawing the > footprints properly. However, sometimes the silkscreen of one > footprint ends up on the pads of another one (think components under a > so-dimm card, for example). The attached patch adds an option to > subtract the soldermask from the silkscreen when doing gerber output. > > marco > Committed in version 2644. Fixed in version 2645. Fixes: function header, space above single line comments, expandable dialog box problems. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/06/2010 04:20 PM, Dick Hollenbeck wrote: > Hi, > >> Board manufacturers typically do not print silkscreen on areas without >> soldermask. Nevertheless, it would be nice to have proper gerbers to >> begin with, i.e., gerbers with no silkscreen in soldermaskless areas. >> Of course, most of the problem can be taken care of by drawing the >> footprints properly. However, sometimes the silkscreen of one >> footprint ends up on the pads of another one (think components under a >> so-dimm card, for example). The attached patch adds an option to >> subtract the soldermask from the silkscreen when doing gerber output. >> >> marco >> >> > Committed in version 2644. > > Fixed in version 2645. > > Fixes: function header, space above single line comments, expandable > dialog box problems. > > Dick > Marco, Did you test the gerber output with gerbview? I am not sure that gerbview can display a file created with the negative layer. If it cannot, I think we should reverse the default setting that you chose, or I would ask you to see if you can patch gerbview. I think it would be bad for pcbnew to generate a gerber that gerbview cannot display. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/07/2010 03:08 AM, Marco Mattila wrote: > I tested the output with gerbview and gerbv. In gerbv everything's ok. > Now that I checked again with gerbview the negative layer kind of > works. However, since negative layers in gerbview are taken care of by > drawing them in background color, the negative stuff will be > "subtracted" from all layers below the negative layer. Fixing this > probably requires that the drawing of a layer is first done onto a > temporary device context/bitmap and blitting the result to the main > window. I can take a look at this. Just having a single bitmap will not change anything that I can see. You did not mention having multiple layer specific bitmaps and then doing combinational logic on their bits into a final destination. What if you just draw the negative layer last onto the screen? Or is the problem a matter of "looking ahead" to detect the negative layer before beginning drawing? Is gerbview losing the "sequence" of operations established in the gerber file? If so, the way the gerber file loading takes place could be an issue, and the container that holds the drawing primitives. > Anyways, the default value of > subtractMaskFromSilk can be changed to false. > I agree, but: at one time there were retentative preferences for all these gerber output settings. I had at one time gone through and added most if not all the settings to a "save to disk mechanism". I don't know that I got all of them, and I don't know that some have been added that recently that did not make it into that savable category. You are familiar with this code now. It was 2 years since I looked at it. It would be wonderful if we could save all the settings. The non-conforming issue there is the layer choices, since they are board specific. Most the other settings are not necessarily board specific. I had once argued for putting more of these kinds of board specific settings into the BOARD, but that was never truly fulfilled. When we get to redoing the BOARD format, we should take a long hard look at this again. > By the way, there's still a problem with the function header in > plot_common.h. The third patch I submitted is correct, I think. > I just saw that 3rd this morning, missed it yesterday because I reacted to the original patch too quickly. Thanks, Dick > marco > > On Tue, Dec 7, 2010 at 12:48 AM, Dick Hollenbeck wrote: > >> On 12/06/2010 04:20 PM, Dick Hollenbeck wrote: >> >>> Hi, >>> >>> >>>> Board manufacturers typically do not print silkscreen on areas without >>>> soldermask. Nevertheless, it would be nice to have proper gerbers to >>>> begin with, i.e., gerbers with no silkscreen in soldermaskless areas. >>>> Of course, most of the problem can be taken care of by drawing the >>>> footprints properly. However, sometimes the silkscreen of one >>>> footprint ends up on the pads of another one (think components under a >>>> so-dimm card, for example). The attached patch adds an option to >>>> subtract the soldermask from the silkscreen when doing gerber output. >>>> >>>> marco >>>> >>>> >>>> >>> Committed in version 2644. >>> >>> Fixed in version 2645. >>> >>> Fixes: function header, space above single line comments, expandable >>> dialog box problems. >>> >>> Dick >>> >>> >> Marco, >> >> Did you test the gerber output with gerbview? >> >> I am not sure that gerbview can display a file created with the negative >> layer. >> >> If it cannot, I think we should reverse the default setting that you >> chose, or I would ask you to see if you can patch gerbview. I think it >> would be bad for pcbnew to generate a gerber that gerbview cannot display. >> >> 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 >> >> > ___ > 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/09/2010 05:51 PM, Marco Mattila wrote: > Drawing the negative layer last is not correct, since it erases > everything below the negative objects in all layers. The attached > patch seems to do the trick right. All layers (=layers as they are > seen in gerbview, not individual layers in a gerber file) are first > drawn into a bitmap and negative objects are drawn in background > color. Then the bitmap itself is used as a mask in blitting the bitmap > onto the screen. > > marco > I should be able to get a look at this over the weekend. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/09/2010 05:51 PM, Marco Mattila wrote: > Drawing the negative layer last is not correct, since it erases > everything below the negative objects in all layers. The attached > patch seems to do the trick right. All layers (=layers as they are > seen in gerbview, not individual layers in a gerber file) are first > drawn into a bitmap and negative objects are drawn in background > color. Then the bitmap itself is used as a mask in blitting the bitmap > onto the screen. > > marco > > On Tue, Dec 7, 2010 at 4:41 PM, Dick Hollenbeck wrote: Marco & JP: I committed something that was very similar to what you submitted. However, I found some significant speed ups: 1) not using GR_OR mode when erasing the background of a negative layer. 2) not using the mask in the Blit() function but rather use wxOR there, which seems to be signicantly faster for some reason. The two changes together are extremely snappy. Please test to make sure this code is equivalent with respect to display results. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 08:37 AM, jean-pierre charras wrote: > Le 12/12/2010 12:04, Marco Mattila a écrit : >> Using OR instead of COPY in blitting does not produce equivalent >> resuilts. Now the appearance of one layer depends on what was drawn >> "below" it. >> >> marco >> >> On Sun, Dec 12, 2010 at 4:33 AM, Dick Hollenbeck wrote: >>> However, I found some significant speed ups: >>> >>> 1) not using GR_OR mode when erasing the background of a negative layer. >>> >>> 2) not using the mask in the Blit() function but rather use wxOR there, >>> which seems to >>> be signicantly faster for some reason. >>> >>> The two changes together are extremely snappy. >>> >>> Please test to make sure this code is equivalent with respect to display >>> results. >>> > I now fixed issue when compiling with USE_WX_ZOOM defined, > i.e. when the device context is responsible to calculate zoom and draw offset. > (blit function seems work only when user scale = 1 and no offset). > > About OR and COPY, each image (gerber layer) is drawn into its memory DC > using COPY, so each image should be OK. > > Combining different images using OR is better than COPY, because one can see > all images (transparency effect), > like all layers in Pcbnew, and do not change Gerber images. > > This code need to be tested now under MacOSX. Jean-Pierre, I did not mean to give the impression that I was done working on the code. It is a little disconcerting having the code change in my editor right out from underneath me, after doing a bzr update. The key to grasping this was *my* question about whether my commit functioned the same as Marco's patch: this implied an intent on my part to fix it if it was not yet working OK. Marco's response should have been taken to mean that I was back to the drawing board. Perhaps I was not clear. But I tried to be. Out of respect for Marco, the statement that using "OR is better than COPY", should be flagged as an opinion. We need to remain respectful of the work of contributing developers if we are going to ever evolve beyond a small team. And today, frankly, even my nose is a little bent out of shape. I do not think we have found the best overall solution yet. I'd ask for the ability to work on the code without having it change underneath me again. I can see advantages to supporting both a blended color view, like we have in PCBNEW and like what I committed, and a solid color view like what Marco presented, perhaps a toggle button can alternate the two drawing effects. Marco, Thanks for your patience. Your code is technically correct, but it has severe performance problems on my system. I have the fastest computer of anybody that I personally know. 64 bit machine, very high end graphics card. Taking from a comment I added to my portion of the Draw function this AM: // On Linux with a large screen, this version is much faster and without flicker, // but gives a PCBNEW look where layer colors blend together. Plus it works // only because the background color is black. But it may be more useable for some. // The difference is due in part because of the cpu cycles needed to create the // monochromatic bitmap above, and the extra time needed to do bit indexing // into the monochromatic bitmap on the blit above. The cost of testing the individual monocromatic bit for each device context bit is proportional to X * Y of the screen, so with "O squared" on screen area. I have a very large screen. And I am having problems with drawing only two layers, not 10 which will be even worse. If we cannot find a faster way to get your desired behaviour, I think we we will have to support it in a toggle mode. So I am happy to spend some more time searching for an optimal solution with you if you do not mind. How do you feel about the toggle button? Both modes have some advantages from a user experience perspective. My code is obviously dependent on the background being black, and that may not always be the case in the future, so I have put a comment in to that effect. I do not think we are done yet. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 12:40 PM, Marco Mattila wrote: > Dick, > > The main point in my reply earlier was just that the visual results > are not equivalent. However, I agree with you that using OR is the way > to go if it is acceptable that things in gerbview will look a little > different than before. At least I'm ok with that. > > Anyways, I think that the graphics we are talking about here is not > very complex and should be doable. Someone mentioned wxGraphicsContext > in the mailing list a while ago and that it should bring a performance > boost. When working on the patch I briefly experimented with wxGCDC > (which I think wraps wxGraphicsContext in a wxDC compatible way?). > However, the performance was pretty bad and since it turned out that > alpha blending was not necessary I didn't continue on that route any > further. > > marco The problem with ORing the colors is that as you get more layers, eventually the intersections all turn white, no? (Ok, on a normal board, we don't have so many mutliple gerber layer intersections, true. But if it can go wrong it eventually will.) Again, I'd like to support both modes from a UI experience point of view. I have some time now to work on this. Regarding your code, we don't know where the bottleneck is. (If we did, we could directly attack it.) So we can start guessing. Let's assume the screen memory is slower than internal memory, this could be the current bottleneck. Plus I am seeing flicker with only two layers, let alone a full stack of gerber layers. This tends to support the theory. I will spend some time and try buffering the screen memory in its own additional wxMemoryDC until the very end. I can spend that time now. Can you make sense of this language from here: http://docs.wxwidgets.org/trunk/classwx_d_c.html#12bed94a15136b9080683f4151042a34 Pay attention to the algorithm used by wx for Windows when the bitmap cannot be used. /useMask/ If true, Blit does a transparent blit using the mask that is associated with the bitmap selected into the source device context. The Windows implementation does the following if MaskBlt cannot be used: 1. Creates a temporary bitmap and copies the destination area into it. 2. Copies the source area into the temporary bitmap using the specified logical function. 3. Sets the masked area in the temporary bitmap to BLACK by ANDing the mask bitmap with the temp bitmap with the foreground colour set to WHITE and the bg colour set to BLACK. 4. Sets the unmasked area in the destination area to BLACK by ANDing the mask bitmap with the destination area with the foreground colour set to BLACK and the background colour set to WHITE. 5. ORs the temporary bitmap with the destination area. 6. Deletes the temporary bitmap. This sequence of operations ensures that the source's transparent area need not be black, and logical functions are supported. As a second test, maybe we can use that same algorithm, for all platforms. It almost sounds as if you can set the background and foreground colors in advance of doing a blit, and have that affect the final outcome of the blit. This is not intuitively obvious, that setting a color in advance of a blit will go into effect during a blit. Those are two schemes to try, and actually they both involve buffering the screen memory, until the end. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
> Sorry, Dick and Marco. > Dick, you are right. > But I am always in a hurry to see enhancements in Kicad, > and sometimes I forget I must wait for guys who spend their valuable time to > work on it. > I apologize. > I'll try to be patient. Apology accepted. Your and my time are both valuable. That is why we should not normally be working on the same thing :) It is like spending resources twice on the same thing. There will be, and have been times that I ask for help, but until that happens, it means I don't need it. Thanks for stepping up, and apologizing, Jean-Pierre. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 02:31 PM, Dick Hollenbeck wrote: >> Sorry, Dick and Marco. >> Dick, you are right. >> But I am always in a hurry to see enhancements in Kicad, >> and sometimes I forget I must wait for guys who spend their valuable time to >> work on it. >> I apologize. >> I'll try to be patient. > > Apology accepted. Your and my time are both valuable. That is why we should > not > normally be working on the same thing :) > > It is like spending resources twice on the same thing. > > There will be, and have been times that I ask for help, but until that > happens, it > means I don't need it. > > Thanks for stepping up, and apologizing, Jean-Pierre. > > > Dick Jean-Pierre, Please don't take anything I've said here to mean that you are not wanted in the *discussions*, that is not what I am trying to say. But there is no point in us both editing the same source file on the same problem. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 01:57 PM, Lorenzo Marcantonio wrote: > On Sun, 12 Dec 2010, Dick Hollenbeck wrote: > >> The problem with ORing the colors is that as you get more layers, eventually >> the >> intersections all turn white, no? >> (Ok, on a normal board, we don't have so many mutliple gerber layer >> intersections, >> true. But if it can go wrong it eventually will.) > A couple of supply layers and two signal parallel or crossing is actually > pretty > normal (in fact some stackups uses power layers to decouple parallel > running traces on different layers). > > I think it will happen pretty soon:D > >> Let's assume the screen memory is slower than internal memory, this could be >> the >> current bottleneck. Plus I am seeing flicker with only two layers, let >> alone a full >> stack of gerber layers. This tends to support the theory. > Blitting is slow, expecially under X. > >> I will spend some time and try buffering the screen memory in its own >> additional >> wxMemoryDC until the very end. > Another option would be to accumulate the image in a memory bitmap and > then blit it. It all depends on the wxMemoryDC performance. Well that is not another option than the one I suggested, please excuse my bad English. I coded it up and it is faster, and the bottleneck has been located. The blitting is slow only when screen memory is in the picture (pardon the pun). The one and only final blit is now the bottleneck, so there is no point in persuing the path of eliminating the monochromatic bitmap. Often screen memory is of a different format than the internal RAM resident bitmaps, and this can be a CPU intensive thing, to convert each pixel. The last remaining opportunity to reduce the time spent doing the last screen blit is to optimize on the dirty area alone. If we could reduce the size of the dirty area, this would *dramatically* improve speed. I think this is only possible though on the layer show/hide clicks, where a layer is coming or going. On the resizing operations, especially when grid is on screen, the entire screen needs to be redrawn, mandating a full sized blit. 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] [PATCH] Option to subtract soldermask from silkscreen in gerber output
On 12/12/2010 04:56 PM, Vesa Solonen wrote: > On Sun, 12 Dec 2010, Dick Hollenbeck wrote: > >> Often screen memory is of a different format than the internal RAM resident >> bitmaps, >> and this can be a CPU intensive thing, to convert each pixel. >> The last remaining opportunity to reduce the time spent doing the last >> screen blit is >> to optimize on the dirty area alone. If we could reduce the size of the >> dirty area, >> this would *dramatically* improve speed. I think this is only possible >> though on the >> layer show/hide clicks, where a layer is coming or going. On the resizing >> operations, >> especially when grid is on screen, the entire screen needs to be redrawn, >> mandating a >> full sized blit. > I think the above sums up the bigger problem of graphics very well. WxDC > technology is from the 90's and so is KiCad's usage of graphics hardware. > KiCad should not mess with low level bitmap operations, but just send the > vector data to the graphics processor (or optimized sw implementation, > like mesa softpipe). Dirty area optimizations were done as EXA protocol > for the X server... This really is not an application level problem, but > wxDC is making it one. The efforts might be better spent on finding > alternative solutions for drawing than wxDC. > > -Vesa I agree. I have lost all my enthusiasm for wxDC. It is nothing I care to spend any more time on. We indeed need to find a better solution. In the next few weeks I will be looking at Hueter's work. 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] EESCHEMA: New design for a distributed library management system.
Hey Guys, After a significant wait, I actually did follow through and put together my thoughts on a distributed library managment system for EESCHEMA. Eventually some of these design ideas could be used on PCBNEW also, but that is not happening yet. I have been thinking about this design for approximately a year. Then 3 months ago began discussing it on the list. Wayne has been very supportive, and then advanced beyond that and actually offered to write the part description grammar spec. Since then, we have been discussing this when we have time, and he has that second part of the design nearly ready to go in the form of the part description language spec, tentatively name "Sweet". There are actually 3 new main concepts being introduced at once: 1) Distributed libraries, with an *abstract* library API. 2) Parts List. 3) Part description language. Taken together, it will basically mean rewriting EESCHEMA to implement all three concepts, and I don't think any one of the concepts can be done without the other two. Wayne and I will be busy over the Christmas holidays, others are welcome to join in. In advance of that work, if you feel you can contribute any improvements to the concepts please let me know soon. I will be coding the LIB manager and at least one or two LIB_SOURCEs, and the PARTS_LIST over the holidays, hopefully. If there is enough time, and assuming Wayne can do the part parsing and get it to me on time, I will also do a preliminary text driven GUI which calls the parser to draw a part on screen, and at that time I'd like to take a look at Torsten's GAL to do the graphics portion of it. It is only a single panel, not a significant commitment to the GAL, but an experiment. The test tool will not initially support GUI editing, only GUI display of what is parsed in text, per previous discussion on this list. You remember how some HTML editors allow you to edit the HTML source and then display the GUI in another panel. I think inkscape may have a similar mode, editing SVG as text, then displaying it. Hopefully Sweet will be easy enough to edit in this way, TBD. To get a look at the distributed library management design, run doxygen on the design.h file in /new, or use the script in there to do that. Output HTML goes into new/html. Be sure not to miss the block diagram graphic at the bottom of the main page. 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: New design for a distributed library management system.
On 12/13/2010 12:47 PM, bennet...@digis.net wrote: > Distributed library, huh! I want to check out the spec, The first part: $ bzr up $ cd /new $ ./make-html.sh or doxygen $ firefox html/index.html The second part: Coming from 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
[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
Wayne and Torsten,
Here is a patch that allows the GAL to compile and run on Ubuntu Lucid x86_64
with *version wxWidgets 2.8.x*
The key thing is the wxWidgets version. The repo seems to be dependent on 2.9.
Moving forward, we're going to need write access to a branch holding this
stuff. I
think we should keep it a separate branch. Kicad's Cmake can be told to do a
checkout
later.
Thanks again to Torsten for what looks to be:
1) great work,
2) conforming to the coding standards, and
3) for patience in the supreme.
Regards,
Dick
=== modified file 'gal/cairo_gal.cpp'
--- gal/cairo_gal.cpp 2010-10-17 22:57:11 +
+++ gal/cairo_gal.cpp 2010-12-13 19:39:57 +
@@ -149,15 +149,26 @@
#if defined( __WXGTK__ )
// Create a new wxClientDC and get the native implementation
m_clientDC = new wxClientDC( this );
+
+#if wxCHECK_VERSION( 2, 9, 0 )
+
m_clientDCimpl = new wxClientDCImpl( m_bufferedDC, this );
m_drawable = m_clientDCimpl -> m_gdkwindow;
+
+#elif wxCHECK_VERSION( 2,8,0 )
+m_clientDCimpl = new wxClientDC( this );
+m_drawable = m_clientDCimpl -> m_window;
+#else
+#error "need wx widgets 2.8 as a minimum"
+#endif
+
m_cairoImage = gdk_cairo_create( m_buffer );
#endif
#if defined(__WXMSW__)
// Get the handle of the current window
m_clientDC = new wxClientDC( this );
-m_hdc = ( ( HDC )( m_clientDC->GetHDC() ) );
+m_hdc = (HDC) m_clientDC->GetHDC();
// Create a buffer
m_dcBuffer = CreateCompatibleDC( m_hdc );
=== modified file 'gal/cairo_gal.h'
--- gal/cairo_gal.h 2010-10-17 22:57:11 +
+++ gal/cairo_gal.h 2010-12-03 08:50:29 +
@@ -217,7 +217,7 @@
wxClientDC* m_clientDC; //!< Client device context; required because drawing outside the paint event
wxBufferedDC* m_bufferedDC; //!< The buffered drawing context
GdkPixmap* m_buffer; //!< The GDK pixmap
-wxClientDCImpl* m_clientDCimpl; //< The system dependent implementation of a ClientDC
+wxClientDC* m_clientDCimpl; //< The system dependent implementation of a ClientDC
GdkDrawable* m_drawable; //!< Gdk Drawable (Drawables are either GdkWindow or GdkPixmap objects)
#endif
=== modified file 'gal/opengl_gal.cpp'
--- gal/opengl_gal.cpp 2010-10-17 22:57:11 +
+++ gal/opengl_gal.cpp 2010-12-03 09:31:29 +
@@ -44,7 +44,7 @@
#endif
OPENGL_GAL::OPENGL_GAL( wxFrame* aParent, wxSize aScreenSize ) :
-wxGLCanvas( aParent, wxID_ANY, glAttributes, wxDefaultPosition, wxDefaultSize, 0, wxT(
+wxGLCanvas( aParent, wxID_ANY, (int*) glAttributes, wxDefaultPosition, wxDefaultSize, 0, wxT(
"GLCanvas" ) )
{
=== modified file 'gal/test/test_gal.cpp'
--- gal/test/test_gal.cpp 2010-10-17 22:57:11 +
+++ gal/test/test_gal.cpp 2010-12-03 09:32:41 +
@@ -618,7 +618,7 @@
wxCMD_LINE_PARAM,
NULL,
NULL,
-"[testline | testpolyline | testrectangle | testcircle | testarc | testpolygon | testgroup | testfont | testtextalignment ]",
+wxT("[testline | testpolyline | testrectangle | testcircle | testarc | testpolygon | testgroup | testfont | testtextalignment ]"),
wxCMD_LINE_VAL_STRING, wxCMD_LINE_PARAM_MULTIPLE },
{ wxCMD_LINE_NONE } };
___
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] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/13/2010 01:48 PM, Dick Hollenbeck wrote: > Wayne and Torsten, > > Here is a patch that allows the GAL to compile and run on Ubuntu Lucid x86_64 > > with *version wxWidgets 2.8.x* > > The key thing is the wxWidgets version. The repo seems to be dependent on > 2.9. > > > Moving forward, we're going to need write access to a branch holding this > stuff. I > think we should keep it a separate branch. Kicad's Cmake can be told to do a > checkout > later. If the *community* decision is to move forward with it. (Seems that could have been a point of mis-understanding.) I am only one voice, but I should get a good look at it over the Christmas break. > Thanks again to Torsten for what looks to be: > > 1) great work, > 2) conforming to the coding standards, and > 3) for patience in the supreme. > > > 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/14/2010 03:22 AM, Martijn Kuipers wrote: > On Dec 14, 2010, at 2:55 AM, Dick Hollenbeck wrote: > >> On 12/13/2010 01:48 PM, Dick Hollenbeck wrote: >>> Wayne and Torsten, >>> >>> Here is a patch that allows the GAL to compile and run on Ubuntu Lucid >>> x86_64 >>> >>> with *version wxWidgets 2.8.x* >>> >>> The key thing is the wxWidgets version. The repo seems to be dependent on >>> 2.9. >>> >>> >>> Moving forward, we're going to need write access to a branch holding this >>> stuff. I >>> think we should keep it a separate branch. Kicad's Cmake can be told to do >>> a checkout >>> later. >> If the *community* decision is to move forward with it. (Seems that could >> have been a >> point of mis-understanding.) I am only one voice, but I should get a good >> look at it >> over the Christmas break. > Great, for me an example (just like you planned) might show me the value of > Torstens' work. Not saying there isn't any, I am just not seeing it (my fault > really). I had a cathartic moment this weekend when the BLIT operations under wxwidgets on linux flunked in the extreme. I don't yet know what the better alternative is yet, just know we need one. For gerbview, cairo and pixman are in my scope, and some research can be put into techiques in gerbv and its graphical foundations, which I think are cairo and pixman. > If I understand correctly you (DIck) are proposing to maintain 2 branches for > a while: > - Kicad as we know it > - Kicad Next Generation I personally am only committing to a design, and to code only a new EESCHEMA foundation. I won't live long enough to create a new Kicad, inclusive of PCBNEW, since I only have several hundred hours to donate each year. I hope it is not just me and Wayne working on this. Wayne is already on board to write critical portions of it, others are welcome. Once the new foundation is poured, pieces of the old EESCHEMA can come over on top of the new foundation, one by one, and during that time we can get a look at each piece separately, to see if it is worth keeping or re-writing. Obviously the old library editor and manager will all go away. The parts list concept is not going to be easy to implement, and the chief struggle there will be providing a user friendly interface experience. That is why I wanted to do that very early, to prove the *UI* and usability experience concepts early in the game. The remote aspects of some of the LIB_SOURCEs don't currently seem as difficult, and they can be implemented incrementally over a long period of time, by any number of people at any time. The design enables that. Some of them will require servers on the back end, and much help is needed to write those, if they are to get done at all. Those servers are not cast in stone, other than they have to work with the LIB_SOURCE running on the client, which is in C++. But the servers themselves can be in any language, could be python, or an apache module, whatever. > If the next generation is as promising as is foreseen, then one day we > (Jean-Pierre) will just bless the next generation branch as the stable one. > Right ? Yes some time will be needed. The real EESCHEMA switch happens when folks start using it, and they will cast that vote when and if they find it superior. Dick > Thanks for all the effort people are putting into Kicad. > > /Martijn > ___ 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: New design for a distributed library management system.
> The remote aspects of some of the LIB_SOURCEs don't currently seem > as difficult, and they can be implemented incrementally over a long > period of time, by any number of people at any time. The design > enables that. Some of them will require servers on the back end, and > much help is needed to write those, if they are to get done at all. > Those servers are not cast in stone, other than they have to work > with the LIB_SOURCE running on the client, which is in C++. But the > servers themselves can be in any language, could be python, or an > apache module, whatever. I wanted to mention a few items that will help illustrate just how powerful this design is. The unit of retrieval from the LIB_SOURCEs is the Sweet text string. Essentially that returned Sweet string is part of the API. However, behind the mechanism of returning this string can be anything. There could for example be a conversion step, converting the part from any other format into the Sweet form. Not only is a conversion process possible, but so is a dynamic creation process. There is a function to "search for a part using a query string". But do not limit that concept to an existing part. We do not have to limit ourselves to a single "query language". We could support several, including a pastebin type ID string. We just have to use whatever query language the LIB_SOURCE supports, and I see some supporting more than our standard one. This is an opportunity to innovate, and to share. 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote: > On Tue, 14 Dec 2010, Dick Hollenbeck wrote: > >> I had a cathartic moment this weekend when the BLIT operations under >> wxwidgets on >> linux flunked in the extreme. >> I don't yet know what the better alternative is yet, just know we need one. >> For >> gerbview, cairo and pixman are in my scope, and some research can be put into >> techiques in gerbv and its graphical foundations, which I think are cairo >> and pixman. > In my experience cairo is slower than anything I've seen (maybe even > a Java2D would be faster). Well you obviously did not recompile the latest gerbview with the patch that was discussed Sunday night. 20 seconds to update 12 gerver layers or so, on a super fast computer. cairo is NOT the slowest. Besides, current testing should speak louder than past experiences. I don't have an opinion yet on what is best for us. I just KNOW it aint what we are using. > Look at gerbv in cairo mode to get an idea. > pixman looks more promising but I've no experience on 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
>> If the next generation is as promising as is foreseen, then one day we >> (Jean-Pierre) will just bless the next generation branch as the stable one. >> Right ? > Yes some time will be needed. The real EESCHEMA switch happens when folks > start using > it, and they will cast that vote when and if they find it superior. More important than Jean-Pierre's blessing, is his help. :) The user's give the blessings. > 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/14/2010 11:34 AM, jean-pierre charras wrote: > Le 14/12/2010 17:06, Dick Hollenbeck a écrit : >> On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote: >>> On Tue, 14 Dec 2010, Dick Hollenbeck wrote: >>> >>>> I had a cathartic moment this weekend when the BLIT operations under >>>> wxwidgets on >>>> linux flunked in the extreme. >>>> I don't yet know what the better alternative is yet, just know we need >>>> one. For >>>> gerbview, cairo and pixman are in my scope, and some research can be put >>>> into >>>> techiques in gerbv and its graphical foundations, which I think are cairo >>>> and pixman. >>> In my experience cairo is slower than anything I've seen (maybe even >>> a Java2D would be faster). >> Well you obviously did not recompile the latest gerbview with the patch that >> was >> discussed Sunday night. >> >> 20 seconds to update 12 gerver layers or so, on a super fast computer. >> >> cairo is NOT the slowest. Besides, current testing should speak louder than >> past >> experiences. I don't have an opinion yet on what is best for us. I just >> KNOW it aint >> what we are using. >> >> >>> Look at gerbv in cairo mode to get an idea. >>> pixman looks more promising but I've no experience on it. >>> > For info: I spent some hours to test latest Gerbview, under Linux Ubuntu > 10.10 , Windows XP and Vista. > I used a 10 layers very large board (9500 pads/vias, 27000 track segments, a > lot of copper areas) > on my computer (a very common and low cost PC with a basic graphic card)with > a single 1200x1000 pixels monitor. > I do not have any speed issues: > The new Gerbview is faster than the old version (at least as fast as Gerbv on > my computer). > The copy mode is roughly as fast as the or mode. > When Gerbview is full screen, it takes about 1 second to redraw the screen > (less than pcbnew to redraw the board). > > So "20 seconds to update 12 gerver layers or so, on a super fast computer" > could be due to an other problem, > even with monitor that have more pixels than mine. > > Having said this, I think if you are motivated to work on a new graphic > alternative using the experimental Torsten's work, > this is a *very good* news. > > I do not know if cairo or an other tool is faster or not. > The answer will come from tests with very large boards on a lot of different > computers and OS. > > But we can find a lot of enhancements (anti aliasing, better and more > powerful graphic primitives ...) > One of most important issues with the current wxDC implementation is the fact > one cannot have a scaling factor for graphic texts. > This is the main reason why Eeschema does not use usual fonts. > > Cairo is a candidate, but have also a look to sfml2: > Developers are actively working on it. > It is multi platform. > It use currently cmake. > It is small. > It could be an other serious candidate. Jean-Pierre, Thanks for the discussion on gerbview. 1920 x 1200 = 2304000 pixels - = 1.92 1200 x 1000 = 120 pixel Yes, it seems you are correct, the area difference is no explanation for this large difference in blit "mask with AND" mode. So the question is, how many users will find themselves with the same problem? Hard to answer if we don't know the reason for the problem. gerbv is MUCH faster on my computer than the latest gerbview using "mask with AND". However, using blit OR mode, gerbview is faster than gerbv. If we can get that button in there to toggle the mode, perhaps we can simply postpone solving the blit "mask with AND" question. = Also, thanks for your thoughts on the graphics subsystem. Actually writing some bit of new code for Torsten's API will provide us with a lot of observations. If the API is sound, most anything can be tucked underneath it. After all, it is a GAL. As far as speed goes, we may not get a good read on the speed until something more demanding is done with it, like a gerbview or pcbnew. EESCHEMA would ask relatively little of the GAL. 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
> Thanks for the discussion on gerbview. > > 1920 x 1200 = 2304000 pixels > - = 1.92 > > 1200 x 1000 = 120 pixel > > > Yes, it seems you are correct, the area difference is no explanation for this > large > difference in blit "mask with AND" mode. Well on second thought, it is not O(screen area). Screen area could be the entire reason. I will try it with a reduced resolution setting soon. 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] New part file format document.
On 12/15/2010 06:19 AM, Brian Sidebotham wrote: > On 14 December 2010 22:49, Wayne Stambaugh wrote: >> I made some ,inor changes to clarify inherited vs base part and changed >> LPID names reflect local naming convention as suggested by Dick. >> >> Wayne >> >> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote: >>> I know all of you've been on the edge of your seats waiting for the the new >>> part file format since Dick announced his plans to start working on the >>> distributed library. So without further ado, attached is the preliminary >>> copy >>> of the library part file specification. Please take a look at it and make >>> sure >>> I didn't forget anything. I have tried to accommodate all of the previous >>> library discussions as best I could. If I missed something, it wasn't >>> intentional so please let me know so I can revise the specification. >>> >>> Initially, I would like keep the discussion focused on what is missing and >>> how >>> it should be implemented. Please keep the discussion on semantics like "I >>> would rather use thickness instead of line_width" until after we've hammered >>> out all of the technical issues. >>> >>> Once we have a consensus, I will convert the document into a more formal >>> format >>> similar to the current file specification documents and commit it to the >>> documentation repo since that is were the rest of Kicad's documentation >>> resides. >>> >>> I know it's been a long time coming so thank you for your patience. >>> >>> Wayne > Hi Wayne, > > I just got a look through the doc. I have a few questions/observations for > you: > > (1) If I browsed a library for a part which contains all of the parts > information below the line: > # This is an example of a dual input NAND gate A of a 7400. > in the document, does this mean that I would see all of the parts for > selection? i.e. dual_input_nand_a, dual_input_nand_b, > dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a, > dual_input_nand_demorgan_b, dual_input_nand_demorgan_c, > dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR > > I would have thought there would need to be a way in the syntax of > showing what was a selectable/finished part and what was merely a > "symbol" or partial part which should not be allowed to be entered > into the schematic directly. Brian, This is a good observation, about the readiness of a part. (Don't mean to butt in, since you asked Wayne.) Three possible solutions to keeping a part off limits for instantiation: 1) Mark the part as not ready for prime time using Sweet. 2) The part parser is dancing through all these part body expressions. Rather than the user saying in syntax that the part is not ready for primetime, it may be possible for the parser to reach such a conclusion and then reflect this in a class PART::state field, indicating that it is syntactically correct, but incompletely specified. 3) We may also be able to do this based on library "category". Categories within a library are directory like partitions, and although I had originally thought that they would apply to all libraries except the parts list, in the last two days I have been wondering if we may be able to or should have them there also, as a tabbed spreadsheet. (The UI paradigm of the parts list is going to be a challenge, it has to be useable.) Remember, the only parts that can be instantiated are those in the parts list. So this brings up a fourth option, which is to say that only prime-time ready parts (i.e. instantiable parts) can go into the parts list. That may be the best option of all. My least favorite is 1). But the conversation extends then not merely to instantiation, but also to extension. For extension, the derived part may live in the parts list, and all base parts have to be available for extension, regardless of their library of origin and regardless of their completeness. So any picklist UI has to show all of them. Dick > Ah, actually, I see you might be using the value field for this > purpose. Only values are selectable parts perhaps? > > (2) I could see a pin rename function being handy. At the moment it is > possible to delete a pin and then add a new pin in, but this would > mean re-defining all of the other pin properties. > > (pin_rename NUMBER NAME) > > Another method might be to have overriding of pin attributes. For example: > > (part “dual_input_nand_a” > (reference “U”) > (pin input line (at -600 100 180) > (name “” (font (size 60 60)) (visible yes)) > (number “1” (font (size 60 60)) (visible yes)) > (visible yes)) > ) > > (part “dual_input_nand_b” inherits “dual_in_nand_a/rev1” > (pin_del 7) > (pin_del 14) > (pin_renum 1 4) > (pin_renum 2 5) > (pin_renum 3 6) > (pin (number "4") (name "D")) > (pin (number "5") (name "E")) > (pin (number "6") (name "F")) > ) > > Perhaps this is something already envisaged? > It will be useful for people who use micro with an inordinate amount > of
Re: [Kicad-developers] New part file format document.
On 12/15/2010 08:35 AM, Wayne Stambaugh wrote:
> On 12/15/2010 8:49 AM, Dick Hollenbeck wrote:
>> On 12/15/2010 06:19 AM, Brian Sidebotham wrote:
>>> On 14 December 2010 22:49, Wayne Stambaugh wrote:
>>>> I made some ,inor changes to clarify inherited vs base part and changed
>>>> LPID names reflect local naming convention as suggested by Dick.
>>>>
>>>> Wayne
>>>>
>>>> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote:
>>>>> I know all of you've been on the edge of your seats waiting for the the
>>>>> new
>>>>> part file format since Dick announced his plans to start working on the
>>>>> distributed library. So without further ado, attached is the preliminary
>>>>> copy
>>>>> of the library part file specification. Please take a look at it and
>>>>> make sure
>>>>> I didn't forget anything. I have tried to accommodate all of the previous
>>>>> library discussions as best I could. If I missed something, it wasn't
>>>>> intentional so please let me know so I can revise the specification.
>>>>>
>>>>> Initially, I would like keep the discussion focused on what is missing
>>>>> and how
>>>>> it should be implemented. Please keep the discussion on semantics like "I
>>>>> would rather use thickness instead of line_width" until after we've
>>>>> hammered
>>>>> out all of the technical issues.
>>>>>
>>>>> Once we have a consensus, I will convert the document into a more formal
>>>>> format
>>>>> similar to the current file specification documents and commit it to the
>>>>> documentation repo since that is were the rest of Kicad's documentation
>>>>> resides.
>>>>>
>>>>> I know it's been a long time coming so thank you for your patience.
>>>>>
>>>>> Wayne
>>> Hi Wayne,
>>>
>>> I just got a look through the doc. I have a few questions/observations for
>>> you:
>>>
>>> (1) If I browsed a library for a part which contains all of the parts
>>> information below the line:
>>> # This is an example of a dual input NAND gate A of a 7400.
>>> in the document, does this mean that I would see all of the parts for
>>> selection? i.e. dual_input_nand_a, dual_input_nand_b,
>>> dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a,
>>> dual_input_nand_demorgan_b, dual_input_nand_demorgan_c,
>>> dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR
>>>
>>> I would have thought there would need to be a way in the syntax of
>>> showing what was a selectable/finished part and what was merely a
>>> "symbol" or partial part which should not be allowed to be entered
>>> into the schematic directly.
>> Brian,
>>
>> This is a good observation, about the readiness of a part. (Don't mean to
>> butt in,
>> since you asked Wayne.)
> Brian,
>
> Good catch. I hadn't actually thought about that.
>
>> Three possible solutions to keeping a part off limits for instantiation:
>>
>> 1) Mark the part as not ready for prime time using Sweet.
>>
>> 2) The part parser is dancing through all these part body expressions.
>> Rather than
>> the user saying in syntax that the part is not ready for primetime, it may
>> be possible
>> for the parser to reach such a conclusion and then reflect this in a class
>> PART::state
>> field, indicating that it is syntactically correct, but incompletely
>> specified.
> My preference would be solution 2. If we change our minds as to what defines
> a
> valid part, we only need to change that in the library code. If we implement
> it as a new part file element, we would have to change it in every part file.
> It also creates additional syntax for the part file. One of my primary goals
> was to keep the part syntax as clean and readable as possible so I will be
> reluctant to add anything that can be solved in code. It should be easy
> enough
> to have the librarian only display valid parts for inclusion into a schematic.
>
> Wayne
Right, I should have given my 4th solution a number 4). Definitely 2) is
needed, and
the good news is 2) and 4) are not mutually exclusive. You could not implement
4)
without 2).
For 2):
During parsing, and in the Inherits() method, we can set bits in a "contains"
bitmap int.
class PART {
Re: [Kicad-developers] New part file format document.
On 12/15/2010 08:46 AM, Dick Hollenbeck wrote: > On 12/15/2010 08:35 AM, Wayne Stambaugh wrote: >> On 12/15/2010 8:49 AM, Dick Hollenbeck wrote: >>> On 12/15/2010 06:19 AM, Brian Sidebotham wrote: >>>> On 14 December 2010 22:49, Wayne Stambaugh wrote: >>>>> I made some ,inor changes to clarify inherited vs base part and changed >>>>> LPID names reflect local naming convention as suggested by Dick. >>>>> >>>>> Wayne >>>>> >>>>> On 12/14/2010 9:39 AM, Wayne Stambaugh wrote: >>>>>> I know all of you've been on the edge of your seats waiting for the the >>>>>> new >>>>>> part file format since Dick announced his plans to start working on the >>>>>> distributed library. So without further ado, attached is the >>>>>> preliminary copy >>>>>> of the library part file specification. Please take a look at it and >>>>>> make sure >>>>>> I didn't forget anything. I have tried to accommodate all of the >>>>>> previous >>>>>> library discussions as best I could. If I missed something, it wasn't >>>>>> intentional so please let me know so I can revise the specification. >>>>>> >>>>>> Initially, I would like keep the discussion focused on what is missing >>>>>> and how >>>>>> it should be implemented. Please keep the discussion on semantics like >>>>>> "I >>>>>> would rather use thickness instead of line_width" until after we've >>>>>> hammered >>>>>> out all of the technical issues. >>>>>> >>>>>> Once we have a consensus, I will convert the document into a more formal >>>>>> format >>>>>> similar to the current file specification documents and commit it to the >>>>>> documentation repo since that is were the rest of Kicad's documentation >>>>>> resides. >>>>>> >>>>>> I know it's been a long time coming so thank you for your patience. >>>>>> >>>>>> Wayne >>>> Hi Wayne, >>>> >>>> I just got a look through the doc. I have a few questions/observations for >>>> you: >>>> >>>> (1) If I browsed a library for a part which contains all of the parts >>>> information below the line: >>>> # This is an example of a dual input NAND gate A of a 7400. >>>> in the document, does this mean that I would see all of the parts for >>>> selection? i.e. dual_input_nand_a, dual_input_nand_b, >>>> dual_input_nand_c, dual_input_nand_d, dual_input_nand_demorgan_a, >>>> dual_input_nand_demorgan_b, dual_input_nand_demorgan_c, >>>> dual_input_nand_demorgan_d, 7400, 74LS00, and SN74HCT00NSR >>>> >>>> I would have thought there would need to be a way in the syntax of >>>> showing what was a selectable/finished part and what was merely a >>>> "symbol" or partial part which should not be allowed to be entered >>>> into the schematic directly. >>> Brian, >>> >>> This is a good observation, about the readiness of a part. (Don't mean to >>> butt in, >>> since you asked Wayne.) >> Brian, >> >> Good catch. I hadn't actually thought about that. >> >>> Three possible solutions to keeping a part off limits for instantiation: >>> >>> 1) Mark the part as not ready for prime time using Sweet. >>> >>> 2) The part parser is dancing through all these part body expressions. >>> Rather than >>> the user saying in syntax that the part is not ready for primetime, it may >>> be possible >>> for the parser to reach such a conclusion and then reflect this in a class >>> PART::state >>> field, indicating that it is syntactically correct, but incompletely >>> specified. >> My preference would be solution 2. If we change our minds as to what >> defines a >> valid part, we only need to change that in the library code. If we implement >> it as a new part file element, we would have to change it in every part file. >> It also creates additional syntax for the part file. One of my primary goals >> was to keep the part syntax as clean and readable as possible so I will be >> reluctant to add anything that can be solved in code. It should be easy >> enough >> to have the librarian only display valid parts for inclusion into a >> schematic. >> >> Wayne > Right, I should have given my 4th solution a number 4). Definitely 2) is > needed, and > the good news is 2) and 4) are not mutually exclusive. You could not > implement 4) > without 2). Since the parts list is the origin of the BOM, we may need to have 4) also, other wise folks will go to buy incomplete parts and get all confused. :) Worse yet, they may come back and ask us where to get those parts. ___ 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] New part file format document.
>> Since the parts list is the origin of the BOM, we may need to have 4) also, >> other wise >> folks will go to buy incomplete parts and get all confused. :) >> >> Worse yet, they may come back and ask us where to get those parts. > It's really difficult to find a good supplier for arcs, rectangles, and lines, > let alone bezier curves :) I'm trying to imagine my reaction if my wife asked me to go buy a 3 legged dog. I'd be tempted to tell her that I am one, but it aint true. ___ 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] New part file format document.
> I didn't use pin_swap in an example because a 7400 is so simple you typically > wouldn't need to swap any pins. I see pin swapping being useful on component > with a lot of reconfigurable pins (think micro-controllers or gate arrays). > The primary usage pattern I see with pin swapping is say I am 90% done wiring > a > 32 bit micro-controller in my schematic when I realize that the last couple of > pins are going to turn my schematic into a rats nest. Rather than rip up all > the work you've just done, you could quickly create a new component based on > the existing one and swap the pins that would allow you to finish wiring your > schematic the way you want it to. I can see pin swapping also finding it's > way > into the schematic edit. I don't see that happening, and this is because components are nothing but instantiated parts. You cannot swap the pins of a component, because technically it does not have any. So this has to happen in the parts list. Behind the scenes you could clone the part to a new parts list entry, and then change the part reference in the component to point to the new part in the parts list. Like I said, it is going to take discipline to hang on to this parts list concept. I'm fully committed to doing that however, so expect resistance from me on concepts that make it difficult to keep the parts list. Sorry. 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] New part file format document.
On 12/15/2010 01:41 PM, Wayne Stambaugh wrote: > On 12/15/2010 2:21 PM, Dick Hollenbeck wrote: >>> I didn't use pin_swap in an example because a 7400 is so simple you >>> typically >>> wouldn't need to swap any pins. I see pin swapping being useful on >>> component >>> with a lot of reconfigurable pins (think micro-controllers or gate arrays). >>> The primary usage pattern I see with pin swapping is say I am 90% done >>> wiring a >>> 32 bit micro-controller in my schematic when I realize that the last couple >>> of >>> pins are going to turn my schematic into a rats nest. Rather than rip up >>> all >>> the work you've just done, you could quickly create a new component based on >>> the existing one and swap the pins that would allow you to finish wiring >>> your >>> schematic the way you want it to. I can see pin swapping also finding it's >>> way >>> into the schematic edit. >> >> I don't see that happening, and this is because components are nothing but >> instantiated parts. You cannot swap the pins of a component, because >> technically it >> does not have any. So this has to happen in the parts list. Behind the >> scenes you >> could clone the part to a new parts list entry, and then change the part >> reference in >> the component to point to the new part in the parts list. >> >> Like I said, it is going to take discipline to hang on to this parts list >> concept. >> I'm fully committed to doing that however, so expect resistance from me on >> concepts >> that make it difficult to keep the parts list. Sorry. > I guess I'm still not 100% sure how all this is going to fit together. The > above should read: Create a new part derived from the existing one and swap > the pins in the inherited part. Change the part in your schematic to your new > part. > > Wayne The definition of "component" in the new doxygen output might help. There is not much to a component. It has no pins itself. The component is in the schematic. It points to a part in the parts list, the part that it "*is*". The component has no pins itself, but borrows those of the part via pointer at the C++ level. To swap pins in a component: Create a new part derived from the component's current one, and swap the pins in the inherited part. Change the component in the schematic such that its part reference points to the new part in the parts list. We'll need reference counting in RAM loaded parts so they cannot be deleted if some higher level entity, part or component, is dependent on them. It is not generally easy to delete a part in the new API. Only possible to delete a part if its LIB has LIB_SINK, and even now I remember this function is missing in LIB_SINK. Currently I don't see the PARTS_LIST class using the LIB_SOURCE+LIB_SINK delegates, since it can override the LIB functions using polymorphism. Hope this helps, 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/15/2010 01:15 AM, jean-pierre charras wrote: > Le 14/12/2010 18:59, Dick Hollenbeck a écrit : >>> Thanks for the discussion on gerbview. >>> >>> 1920 x 1200 = 2304000 pixels >>> - = 1.92 >>> >>> 1200 x 1000 = 120 pixel >>> >>> >>> Yes, it seems you are correct, the area difference is no explanation for >>> this large >>> difference in blit "mask with AND" mode. >> >> Well on second thought, it is not O(screen area). >> >> Screen area could be the entire reason. >> >> I will try it with a reduced resolution setting soon. >> >> Dick >> > I forgot: > > If you are compiling with option USE_WX_ZOOM = ON, the patch has a bug in > BOARD::Draw. > line > aPanel->DrawBackGround( &screenDC ); > must be > aPanel->DoPrepareDC(screenDC); > aPanel->DrawBackGround( &screenDC ); > > Otherwise, if the grid display option is ON, the grid is always drawn, > regardless the grid size in pixels, > because in the current device context, the user scale is set to 1.0, and > testing to see if the grid size in pixel is more than 10 > pixels fails. > > For zoom values of 16 and more, the grid drawing routine is therefore very > long and can easily explain 20 seconds to redraw the > screen. > Roughly, the grid routine try to draw the grid on a screen size of zoom * > screen_size_x * zoom * screen_size_y. > If the grid size is low and zoom value hight, it takes a while. > > (Can be avoid if you switch the grid display OFF) Jean-Pierre, I have 15 *.pho files associated with the board I had sent you for debugging the zones. Fifteen *.pho layers. That screen redraws in 1.8 seconds using the "bitmask with COPY" mode. On a full screen. *The twenty seconds was a bad report, sorry.* I think I loaded the gerbers on the command line with "ks*.pho" and ended up with 30 gerbers, since there were two root filename sets, say ks1*.pho and ks2*.pho. My bad. But it was never 20 seconds, just feld like it, and mostly because the loading of the gerbers redraws the screen after each individual layer. In the OR mode, it is faster. If I scrink the screen, it gets faster, goes down to 0.7 seconds or so, approximately proportional to screen area. The grid had not much effect that I could tell. I think the 1.8 seconds is tolerable for now. And the faster OR mode even more so. I really like the look of the "bitmask with COPY" mode. It would be nice to have both modes. Lastly until I buffered using screenDC, I had been getting screen flashing using the "bitmap with COPY" mode. So I think we need to keep that, or something like it. GetBoard()->Draw( DrawPanel, DC, GR_COPY, // this needs to be GR_COPY or GR_OR, set from a toggle button. wxPoint( 0, 0 ) ); That argument GR_COPY, if it could be button toggled to GR_OR, with the other TODO items I mentioned when I emailed the patch, would probably make for an excellent step forward for this tool. 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/15/2010 04:16 PM, Dick Hollenbeck wrote: > On 12/15/2010 01:15 AM, jean-pierre charras wrote: >> Le 14/12/2010 18:59, Dick Hollenbeck a écrit : >>>> Thanks for the discussion on gerbview. >>>> >>>> 1920 x 1200 = 2304000 pixels >>>> - = 1.92 >>>> >>>> 1200 x 1000 = 120 pixel >>>> >>>> >>>> Yes, it seems you are correct, the area difference is no explanation for >>>> this large >>>> difference in blit "mask with AND" mode. >>> Well on second thought, it is not O(screen area). >>> >>> Screen area could be the entire reason. >>> >>> I will try it with a reduced resolution setting soon. >>> >>> Dick >>> >> I forgot: >> >> If you are compiling with option USE_WX_ZOOM = ON, the patch has a bug in >> BOARD::Draw. >> line >> aPanel->DrawBackGround( &screenDC ); >> must be >> aPanel->DoPrepareDC(screenDC); >> aPanel->DrawBackGround( &screenDC ); >> >> Otherwise, if the grid display option is ON, the grid is always drawn, >> regardless the grid size in pixels, >> because in the current device context, the user scale is set to 1.0, and >> testing to see if the grid size in pixel is more than 10 >> pixels fails. >> >> For zoom values of 16 and more, the grid drawing routine is therefore very >> long and can easily explain 20 seconds to redraw the >> screen. >> Roughly, the grid routine try to draw the grid on a screen size of zoom * >> screen_size_x * zoom * screen_size_y. >> If the grid size is low and zoom value hight, it takes a while. >> >> (Can be avoid if you switch the grid display OFF) > Jean-Pierre, > > I have 15 *.pho files associated with the board I had sent you for debugging > the > zones. Fifteen *.pho layers. That screen redraws in 1.8 seconds using the > "bitmask > with COPY" mode. > On a full screen. > > *The twenty seconds was a bad report, sorry.* > > I think I loaded the gerbers on the command line with "ks*.pho" and ended up > with 30 > gerbers, since there were two root filename sets, say ks1*.pho and ks2*.pho. > My bad. > But it was never 20 seconds, just feld like it, and mostly because the > loading of the > gerbers redraws the screen after each individual layer. > > In the OR mode, it is faster. > > If I scrink the screen, it gets faster, goes down to 0.7 seconds or so, > approximately > proportional to screen area. The grid had not much effect that I could tell. > > I think the 1.8 seconds is tolerable for now. And the faster OR mode even > more so. > > I really like the look of the "bitmask with COPY" mode. > > It would be nice to have both modes. > > Lastly until I buffered using screenDC, I had been getting screen flashing > using the > "bitmap with COPY" mode. So I think we need to keep that, or something like > it. > > > GetBoard()->Draw( DrawPanel, DC, > GR_COPY, // this needs to be GR_COPY or > GR_OR, set > from a toggle button. > wxPoint( 0, 0 ) ); > > > That argument GR_COPY, if it could be button toggled to GR_OR, with the other > TODO > items I mentioned when I emailed the patch, would probably make for an > excellent step > forward for this tool. the competing gerbv draws the same gerber stack in about 0.8 seconds using the same size, etc. It its presentation seems more like our "bitmask with COPY" mode. ___ 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] New part file format document.
> The only thing not covered for me then would be one schematic pin to > many footprint pins support. I can't see a nice way of doing that yet. Brian, Even with the current software, try adding pins to your footprint that share the same pin name. I believe the netlist will know then that these pins are all equivalent and are mapped to the very one and the same schematic pin. I remember doing this, so I think its there now. 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] New part file format document.
On 12/16/2010 06:18 AM, Brian Sidebotham wrote: > On 16 December 2010 02:31, Wayne Stambaugh wrote: >> On 12/15/2010 9:19 PM, Karl Schmidt wrote: >>> On 12/15/2010 07:30 PM, Brian Sidebotham wrote: >>> >>> When placing components such as passives (mainly R's and C's) you come across the common problem that you draw the symbol either horizontally or vertically. When you place the component it could be in one of four orientations, but generally it's either 0deg rot (horizontal) or 90deg rot (vertical). >>> This is called Schematic symbol alternatives - usually you only need 2 >>> versions (bridge circuits need a 45 makes 3 versions) - most CAD systems >>> have this - and its nice. I added this to my wiki's wish list. >> This would this not be a feature in the schematic capture program? An >> excellent idea but I don't see it as a requirement of the part file or >> the part file editor. >> >> Wayne > It does need a way of telling the schematic capture how to choose a > look for a component. However, I think the functionality is allowed > for in the current spec already. The different versions can be > alternatives, then it is down to the GUI design to make these > alternatives easy to select on a per-component instance basis which > I'm sure is possible, and if I remember rightly desired by Jean-Pierre > for large logic designs too for selecting deMorgan. > > So I think this is already covered, I hadn't thought about using > alternatives for this in the part spec. This also covers different > pinouts for processors that are available in different packages. Yes, maybe there is a way for "alternate like" keywords to assist in the dynamic construction of [pop up or other kinds of] menus during part picking. Dick > The only thing not covered for me then would be one schematic pin to > many footprint pins support. I can't see a nice way of doing that yet. > It's only a nice-to-have anyway, and that's only my opinion which > generally seems to differ from most others! ;) > > Thanks again for all the efforts, I'm really seeing Dick's vision of > editing the source of the part in the editor as it's so easy to read > and follow. Well Done All! > > Best Regards, > > Brian. > > ___ > 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] New part file format document.
> Brian, > > Even with the current software, try adding pins to your footprint that share > the same > pin pad > name. I believe the netlist will know then that these pins pads > are all equivalent and > are mapped to the very one and the same schematic pin. I remember doing > this, so I > think its there now. > > 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] New part file format document.
On 12/16/2010 08:12 AM, Wayne Stambaugh wrote: > On 12/16/2010 7:18 AM, Brian Sidebotham wrote: >> On 16 December 2010 02:31, Wayne Stambaugh wrote: >>> On 12/15/2010 9:19 PM, Karl Schmidt wrote: On 12/15/2010 07:30 PM, Brian Sidebotham wrote: > When placing components such as passives (mainly R's and C's) you come > across the common problem that you draw the symbol either horizontally > or vertically. When you place the component it could be in one of four > orientations, but generally it's either 0deg rot (horizontal) or 90deg > rot (vertical). This is called Schematic symbol alternatives - usually you only need 2 versions (bridge circuits need a 45 makes 3 versions) - most CAD systems have this - and its nice. I added this to my wiki's wish list. >>> This would this not be a feature in the schematic capture program? An >>> excellent idea but I don't see it as a requirement of the part file or >>> the part file editor. >>> >>> Wayne >> It does need a way of telling the schematic capture how to choose a >> look for a component. However, I think the functionality is allowed >> for in the current spec already. The different versions can be >> alternatives, then it is down to the GUI design to make these >> alternatives easy to select on a per-component instance basis which >> I'm sure is possible, and if I remember rightly desired by Jean-Pierre >> for large logic designs too for selecting deMorgan. >> >> So I think this is already covered, I hadn't thought about using >> alternatives for this in the part spec. This also covers different >> pinouts for processors that are available in different packages. >> >> The only thing not covered for me then would be one schematic pin to >> many footprint pins support. I can't see a nice way of doing that yet. >> It's only a nice-to-have anyway, and that's only my opinion which >> generally seems to differ from most others! ;) > Conceptually its a merge action so the syntax would look like: > > (pin_merge PIN_LIST) > > The part and schematic editors would only display the first pin in the list. > The schematic net list generator would electrically connect all of the pins in > the list. > > The other option is to tell the schematic editor to merge all power pins with > the same name. So all pins named GND, VCC, etc. would be merged into a single > pin for display purposes. This behavior could even be applied per component > and saved a part of the yet to be written new schematic file format. > > My preference would be to make this an option in the schematic editor since it > doesn't really effect the part itself. It only effects how the part is > displayed. Anyone else have any thoughts. Its yucky? Maybe a netlist editor in PCBNEW is an alternative? Don't know, medicine is sometimes yucky too. But like medicine, if it can be taken only when you need it, and there is no other way... This is one of those areas where you need multiple solutions to the problem on the table, before chosing what you think is the best of 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] New part file format document.
On 12/16/2010 08:12 AM, Wayne Stambaugh wrote: > On 12/16/2010 7:18 AM, Brian Sidebotham wrote: >> On 16 December 2010 02:31, Wayne Stambaugh wrote: >>> On 12/15/2010 9:19 PM, Karl Schmidt wrote: On 12/15/2010 07:30 PM, Brian Sidebotham wrote: > When placing components such as passives (mainly R's and C's) you come > across the common problem that you draw the symbol either horizontally > or vertically. When you place the component it could be in one of four > orientations, but generally it's either 0deg rot (horizontal) or 90deg > rot (vertical). This is called Schematic symbol alternatives - usually you only need 2 versions (bridge circuits need a 45 makes 3 versions) - most CAD systems have this - and its nice. I added this to my wiki's wish list. >>> This would this not be a feature in the schematic capture program? An >>> excellent idea but I don't see it as a requirement of the part file or >>> the part file editor. >>> >>> Wayne >> It does need a way of telling the schematic capture how to choose a >> look for a component. However, I think the functionality is allowed >> for in the current spec already. The different versions can be >> alternatives, then it is down to the GUI design to make these >> alternatives easy to select on a per-component instance basis which >> I'm sure is possible, and if I remember rightly desired by Jean-Pierre >> for large logic designs too for selecting deMorgan. >> >> So I think this is already covered, I hadn't thought about using >> alternatives for this in the part spec. This also covers different >> pinouts for processors that are available in different packages. >> >> The only thing not covered for me then would be one schematic pin to >> many footprint pins support. I can't see a nice way of doing that yet. >> It's only a nice-to-have anyway, and that's only my opinion which >> generally seems to differ from most others! ;) > Conceptually its a merge action so the syntax would look like: > > (pin_merge PIN_LIST) The danger on the mailing list, or in any conversation, is not adequately reading or listening. This is not a bad idea. If we can have the above verb, i.e. "_merge" during parsing mean: 1) hide all pins but the first by toggling a flag in the pin C++ structure. 2) and control how the netlist is generated later Then you are done. The idea may actually be good after all. We need to avoid having to parse during DRAWING of the part, that would be a bad design, but I think we've steered clear of that with this option. 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] New part file format document.
On 12/16/2010 10:33 AM, Wayne Stambaugh wrote: > On 12/16/2010 10:22 AM, Dick Hollenbeck wrote: >> On 12/16/2010 08:12 AM, Wayne Stambaugh wrote: >>> On 12/16/2010 7:18 AM, Brian Sidebotham wrote: >>>> On 16 December 2010 02:31, Wayne Stambaugh wrote: >>>>> On 12/15/2010 9:19 PM, Karl Schmidt wrote: >>>>>> On 12/15/2010 07:30 PM, Brian Sidebotham wrote: >>>>>> >>>>>> >>>>>>> When placing components such as passives (mainly R's and C's) you come >>>>>>> across the common problem that you draw the symbol either horizontally >>>>>>> or vertically. When you place the component it could be in one of four >>>>>>> orientations, but generally it's either 0deg rot (horizontal) or 90deg >>>>>>> rot (vertical). >>>>>> This is called Schematic symbol alternatives - usually you only need 2 >>>>>> versions (bridge circuits need a 45 makes 3 versions) - most CAD systems >>>>>> have this - and its nice. I added this to my wiki's wish list. >>>>> This would this not be a feature in the schematic capture program? An >>>>> excellent idea but I don't see it as a requirement of the part file or >>>>> the part file editor. >>>>> >>>>> Wayne >>>> It does need a way of telling the schematic capture how to choose a >>>> look for a component. However, I think the functionality is allowed >>>> for in the current spec already. The different versions can be >>>> alternatives, then it is down to the GUI design to make these >>>> alternatives easy to select on a per-component instance basis which >>>> I'm sure is possible, and if I remember rightly desired by Jean-Pierre >>>> for large logic designs too for selecting deMorgan. >>>> >>>> So I think this is already covered, I hadn't thought about using >>>> alternatives for this in the part spec. This also covers different >>>> pinouts for processors that are available in different packages. >>>> >>>> The only thing not covered for me then would be one schematic pin to >>>> many footprint pins support. I can't see a nice way of doing that yet. >>>> It's only a nice-to-have anyway, and that's only my opinion which >>>> generally seems to differ from most others! ;) >>> Conceptually its a merge action so the syntax would look like: >>> >>> (pin_merge PIN_LIST) >> The danger on the mailing list, or in any conversation, is not adequately >> reading or >> listening. >> >> This is not a bad idea. If we can have the above verb, i.e. "_merge" during >> parsing mean: >> >> 1) hide all pins but the first by toggling a flag in the pin C++ structure. >> >> 2) and control how the netlist is generated later >> >> >> Then you are done. The idea may actually be good after all. >> >> We need to avoid having to parse during DRAWING of the part, that would be a >> bad >> design, but I think we've steered clear of that with this option. > Makes sense to me. The only question left to answer is do we limit pin merge > to inherited parts only or do we allow it anywhere. If in the PART class, we support a list of lists: i.e. list of merge lists in binary form, then they can be carried forward in the PART::Inherit( PART* base ) function just fine from base parts. This function is essentially an application specific PART:: operator=() like function. It needs to copy all the pins, even onces hidden via merge in base, and the already parsed binary merge lists. PART::Format(?) should be do-able also, I will put some ideas into design.h soon on that. == Commas: not really used in s-expressions, got whitespace for separation of list elements. ___ 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] New part file format document.
On 12/16/2010 12:15 PM, Dick Hollenbeck wrote: > On 12/16/2010 10:33 AM, Wayne Stambaugh wrote: >> On 12/16/2010 10:22 AM, Dick Hollenbeck wrote: >>> On 12/16/2010 08:12 AM, Wayne Stambaugh wrote: >>>> On 12/16/2010 7:18 AM, Brian Sidebotham wrote: >>>>> On 16 December 2010 02:31, Wayne Stambaugh wrote: >>>>>> On 12/15/2010 9:19 PM, Karl Schmidt wrote: >>>>>>> On 12/15/2010 07:30 PM, Brian Sidebotham wrote: >>>>>>> >>>>>>> >>>>>>>> When placing components such as passives (mainly R's and C's) you come >>>>>>>> across the common problem that you draw the symbol either horizontally >>>>>>>> or vertically. When you place the component it could be in one of four >>>>>>>> orientations, but generally it's either 0deg rot (horizontal) or 90deg >>>>>>>> rot (vertical). >>>>>>> This is called Schematic symbol alternatives - usually you only need 2 >>>>>>> versions (bridge circuits need a 45 makes 3 versions) - most CAD systems >>>>>>> have this - and its nice. I added this to my wiki's wish list. >>>>>> This would this not be a feature in the schematic capture program? An >>>>>> excellent idea but I don't see it as a requirement of the part file or >>>>>> the part file editor. >>>>>> >>>>>> Wayne >>>>> It does need a way of telling the schematic capture how to choose a >>>>> look for a component. However, I think the functionality is allowed >>>>> for in the current spec already. The different versions can be >>>>> alternatives, then it is down to the GUI design to make these >>>>> alternatives easy to select on a per-component instance basis which >>>>> I'm sure is possible, and if I remember rightly desired by Jean-Pierre >>>>> for large logic designs too for selecting deMorgan. >>>>> >>>>> So I think this is already covered, I hadn't thought about using >>>>> alternatives for this in the part spec. This also covers different >>>>> pinouts for processors that are available in different packages. >>>>> >>>>> The only thing not covered for me then would be one schematic pin to >>>>> many footprint pins support. I can't see a nice way of doing that yet. >>>>> It's only a nice-to-have anyway, and that's only my opinion which >>>>> generally seems to differ from most others! ;) >>>> Conceptually its a merge action so the syntax would look like: >>>> >>>> (pin_merge PIN_LIST) >>> The danger on the mailing list, or in any conversation, is not adequately >>> reading or >>> listening. >>> >>> This is not a bad idea. If we can have the above verb, i.e. "_merge" >>> during parsing mean: >>> >>> 1) hide all pins but the first by toggling a flag in the pin C++ structure. >>> >>> 2) and control how the netlist is generated later >>> >>> >>> Then you are done. The idea may actually be good after all. >>> >>> We need to avoid having to parse during DRAWING of the part, that would be >>> a bad >>> design, but I think we've steered clear of that with this option. >> Makes sense to me. The only question left to answer is do we limit pin merge >> to inherited parts only or do we allow it anywhere. > If in the PART class, we support a list of lists: > > i.e. list of merge lists in binary form, then they can be carried forward in > the > > PART::Inherit( PART* base ) function just fine from base parts. This > function is > essentially an application specific > > PART:: operator=() > > like function. It needs to copy all the pins, even onces hidden via merge in > base, > and the already parsed binary merge lists. Well I guess if schematic pins can have non-numeric names, then this is not necessarily "binary" is it, I guess we are working with strings all the way through. The merge lists do not get used again until netlist generation time that I can see, or unless: The user wants to add in another pin later in derived part, into an existing merge list. There's probably a way to do that, sort the pins, create a concatonation of all the names in the list, use that as a lookup into the list of lists. Parser coder person decides. 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] New part file format document.
Some aid comes from making the list of lists be just a simple std::set where the contained string is a sorted list of space separated pins. This gets pretty easy then. Can you then support: base class: (pin_merge A B) derived class: (pin_merge B A C D) The remaining problem is that you do not know what to look up, there is no separator between AB (old) & CD (new) The list of lists may not be the only path to persue. Another idea might be to put an integer "merge_code" in each pin, and tie the pins together that way. The merge_code is simply a number that increments uniquely within each PART for each *unique*, not additive merge list. The merge_code for pins not merged could be zero. Probably still missing something, but again, coder decides. ___ 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] New part file format document.
On 12/16/2010 02:50 PM, Simon Rogers wrote: > Could the schematic support multiple parts lists? > > I'm thinking of the problem supporting different builds say a European > version or a US version where the schematic is the same but with > component value changes due to, for example, 50Hz or 60Hz supply or the > different voltages, regulations etc. > No, that's a can of worms. ___ 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] New part file format document.
On 12/14/2010 04:49 PM, Wayne Stambaugh wrote: > I made some ,inor changes to clarify inherited vs base part and changed > LPID names reflect local naming convention as suggested by Dick. > > Wayne Wayne and others, I coded the initial major portion of DIR_LIB_SOURCE this weekend. I believe the design is still holding water, so far. The only thing that has come up is this age old issue of content in container, and names. Let me generalize, so you can see it is not specific to this design. Assume you have a C++ file, and you decide to put the name of the file INTO the file as a string. You load that C++ text file, and save it by another name. The file now lives in two *containers*. 1) The text editor is a container, and it assigns a name to the text file in memory. 2) The filesystem is a container, and it assigns a name to the text file on disk. Each container has its own understanding of the name of the content (i.e. text file). A disagreement has happened. And it is not about the name in the editor and the name on disk. It is about the name IN THE FILE, and the name in the editor and on disk. Either of the two examples of "content (text file) within container" would suffice to make my point: as long as you put the name of the file in the file, there is always the potential for a disagreement between what the file's container thinks the content is named, and what the contained name says. Therefore, we might want to re-think our Sweet token that we referred to as "NAME" (part NAME [extends LPID] .. ) and either drop it, since the Sweet string will always be in some kind of container, or realize that this is not *really* the name of the part, the container will always chose that. A useful comprimize is to conceptually or actually change NAME to SHORT_DESCRIPTION, but if you have a description elsewhere, a short description may not be needed at all. Think about it. The only time when the container will not name the content, may be on the clipboard. A fast answer is probably a wrong answer. I've been thinking about it for a day and still need more time to state the best solution. I just know that the problem will exist as we now have things, and as stated, it is not a problem unique to this design. The container's name will always really dominate, since that is the mechanism used to find units of content. 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] New part file format document.
On 12/20/2010 02:29 PM, Wayne Stambaugh wrote: > On 12/20/2010 1:42 PM, Dick Hollenbeck wrote: >> On 12/14/2010 04:49 PM, Wayne Stambaugh wrote: >>> I made some ,inor changes to clarify inherited vs base part and changed >>> LPID names reflect local naming convention as suggested by Dick. >>> >>> Wayne >> >> Wayne and others, >> >> >> I coded the initial major portion of DIR_LIB_SOURCE this weekend. I believe >> the design is still >> holding water, so far. >> >> >> The only thing that has come up is this age old issue of content in >> container, and names. >> >> Let me generalize, so you can see it is not specific to this design. >> >> Assume you have a C++ file, and you decide to put the name of the file INTO >> the file as a string. >> >> You load that C++ text file, and save it by another name. >> >> The file now lives in two *containers*. >> >> >> >> 1) The text editor is a container, and it assigns a name to the text file in >> memory. >> >> >> 2) The filesystem is a container, and it assigns a name to the text file on >> disk. >> >> >> Each container has its own understanding of the name of the content (i.e. >> text file). A >> disagreement has happened. And it is not about the name in the editor and >> the name on disk. >> >> It is about the name IN THE FILE, and the name in the editor and on disk. >> >> >> >> >> Either of the two examples of "content (text file) within container" would >> suffice to make my point: >> >> >> as long as you put the name of the file in the file, there is always >> the potential for a disagreement between what the file's container >> thinks the content is named, and what the contained name says. >> >> >> Therefore, we might want to re-think our Sweet token that we referred to as >> "NAME" >> >> (part NAME [extends LPID] >> .. >> ) >> >> and either drop it, since the Sweet string will always be in some kind of >> container, or realize that >> this is not *really* the name of the part, the container will always chose >> that. > I actually considered this when I wrote the specification. I don't remember > why I chose to include NAME in the part syntax. I think it's a great idea. > Using the file name as the part name makes sense to me. > >> >> A useful comprimize is to conceptually or actually change NAME to >> SHORT_DESCRIPTION, but if you have >> a description elsewhere, a short description may not be needed at all. > A description (short or otherwise) seems like a good candidate for a property. > I'm not sure if it should be a reserved property or a user definable > property. > >> Think about it. The only time when the container will not name the content, >> may be on the clipboard. > Would you even need the name in the clipboard? If you are pasting into > another > part file, it will take the name of the new part file. You may need to name > them when they become components in a schematic but that would be part of the > schematic file format. > >> A fast answer is probably a wrong answer. I've been thinking about it for a >> day and still need more >> time to state the best solution. > Let me know so I can update the specification. I have already made the > changes > for providing pin and gate swapping flags to be passed to external tools. I > want to keep the specification synced with the code as much as possible to > avoid confusion. > > Wayne Another idea to consider, along with others until a decision is made, is: put a comment into the file to act as a 'hint' only. The hint is only consulted when the part is outside its container. Some cases are if you have it on the clipboard or it is printed out on paper, or it in an email message. Actually with email it might have a filename as an attachment. Ok, say you email it inline. The hint might look like this, and the hint can be ignored by any tool not interested: # partname: 7400 # other comments you might have put into the file. : (part [extends LPID] : ) PART::Format() could output it up at the top as a comment, if requested. Regarding part "description", it seems like this is worthy of more discussion on its own at some point. A useful description block could be: 1) potentially more than one line. 2) shown in a multi-line panel [maybe only] during picklist usage. I don't see it being like properties, all of which can go into the schematic view, but maybe I have to just jam it into my head. Not urgent. If I jam it now, something else will have to fall out to make room. 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] New part file format document.
| Another idea to consider, along with others until a decision is made, is: > put a comment into the file to act as a 'hint' only. The hint is only > consulted when the part is > outside its container. Some cases are if you have it on the clipboard or it > is printed out on > paper, or it in an email message. Actually with email it might have a > filename as an attachment. > Ok, say you email it inline. > > The hint might look like this, and the hint can be ignored by any tool not > interested: > > # partname: 7400 > # other comments you might have put into the file. > : > (part [extends LPID] > : > ) > > PART::Format() could output it up at the top as a comment, if requested. > > > Regarding part "description", it seems like this is worthy of more discussion > on its own at some > point. A useful description block could be: > > 1) potentially more than one line. > 2) shown in a multi-line panel [maybe only] during picklist usage. > > I don't see it being like properties, all of which can go into the schematic > view, but maybe I have > to just jam it into my head. > > Not urgent. If I jam it now, something else will have to fall out to make > room. > > Dick My current leanings are: 1) for (part NAME), leave it in the grammar, but change it to NAME_HINT in the documentation, and describe it as a hint only. 2) Maybe treat the comment text above the (part) element in the sweet string as the description text for eventual use in a picklist side-car panel. 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] l-marcantonio wants to join
On 12/21/2010 01:47 AM, KiCad Bug Squad wrote: > Hello Dick Hollenbeck, > > Lorenzo Marcantonio (l-marcantonio) wants to be a member of KiCad Bug > Squad (kicad-bug-squad), but this is a moderated team, so that > membership has to be approved. You can approve, decline or leave it as > proposed by following the link below. > > https://launchpad.net/~kicad-bug-squad/+member/l-marcantonio > Lorenzo, I am denying your request to add you to Kicad-Bug-Squad since you are already a member, by virtue of your membership in kicad-testing-committers. All members of team kicad-testing-committers are members of team Kicad-Bug-Squad since the team is a member of the other team. Kicad-Bug-Sqaud will occasionally accept team member, but it only makes sense if they are not in kicad-testing-committers already. If you find you need more control over your bug servicing efforts, I don't think it is related to team membership, but rather some setting on the "Bugs" page. Hope this clarifies, 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] reporting bugs against a recent version
On 12/21/2010 01:47 AM, jean-pierre charras wrote: > (2010-03-14)-final is fully outdated. > Do not report bugs before testing a recent kicad version (currently > 2010-12-18-BZR2668-RC2) > Wouldn't that be wonderful. You even say what is "recent", so nobody has any excuses. Thanks for all you do Jean-Pierre. Dick Let's not forget that we will always need a recent definition of recent. ___ 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] New part file format document.
On 12/26/2010 11:14 PM, Chris Giorgi wrote: > Good evening, > > I've been lurking on this thread for quite a while and feel this topic > is one I should chime in on. > > The concept of keeping part names as filenames sounds promising on its > face, but I can envision several potential pitfalls. First, it > requires that the parts be stored in a filesystem to have proper > context, and contain one part per file. This limits the ability to > store parts in a database conveniently, makes it difficult to > implement parts archives as flat files for interchange of libraries, > and makes some names impossible to encode ( how do you handle a '*' in > a part number?, what about a '/'? Resort to escape codes?). In my > opinion, the filename should be allowed to be totally random (such as > automatically downloaded content often is) without loss of important > information. Filename collisions can be avoided entirely, and > conflicting parts can be identified even if you have "partnum.part" > and "partnum (1).part" from downloading two different libraries with > the same name. > >~~~Chris Giorgi~~~ $ grep -r 'DEF ' /usr/local/share/kicad/library/*.lib | grep 'DEF .+/' turns up nothing. Please read the actual design document, not merely the Sweet grammar document and some email postings if you want to be taken seriously. 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] lib table format
(lib_table (lib (logical "LOGICAL")(type "TYPE")(fullURI "FULL_URI")(options "OPTIONS")) (lib (logical "LOGICAL")(type "TYPE")(fullURI "FULL_URI")(options "OPTIONS")) (lib (logical "LOGICAL")(type "TYPE")(fullURI "FULL_URI")(options "OPTIONS")) : ) Its late, but the above is what I'm thinking will comprize a "library table fragment". The overall library table will come from the combination of a personal table fragment and schematic resident fragment. In the morning I will be writing a parser for this grammar. (Somebody else can do a library table editor if they want. I would not have time to get to an editor for awhile, at least not until we start having such a fragment show up in a new schematic file.) Same parser will be able to grab a fragment from either a schematic, or from a separate disk file in the case of a personal table fragment. 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] Compiling probems
On 12/27/2010 09:42 PM, Martin wrote: > since dsnlexer introduced, the same problem appears: > > In file included from /home/martin/kicad/include/richio.h:41, > > from /home/martin/kicad/include/dsnlexer.h:34, > from /home/martin/kicad/common/dsnlexer.cpp:33: > /home/martin/kicad/include/kicad_exceptions.h:54: error: > ‘IO_ERROR::IO_ERROR(const char*)’ cannot be overloaded > /home/martin/kicad/include/kicad_exceptions.h:44: error: with > ‘IO_ERROR::IO_ERROR(const wxChar*)’ > make[2]: *** [common/CMakeFiles/common.dir/dsnlexer.cpp.o] Error 1 > make[1]: *** [common/CMakeFiles/common.dir/all] Error 2 > make: *** [all] Error 2 > > > greetings > Martin Kratoska I'll fix it in a few 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] Compiling probems
On 12/27/2010 09:42 PM, Martin wrote: > since dsnlexer introduced, the same problem appears: > > In file included from /home/martin/kicad/include/richio.h:41, > > from /home/martin/kicad/include/dsnlexer.h:34, > from /home/martin/kicad/common/dsnlexer.cpp:33: > /home/martin/kicad/include/kicad_exceptions.h:54: error: > ‘IO_ERROR::IO_ERROR(const char*)’ cannot be overloaded > /home/martin/kicad/include/kicad_exceptions.h:44: error: with > ‘IO_ERROR::IO_ERROR(const wxChar*)’ > make[2]: *** [common/CMakeFiles/common.dir/dsnlexer.cpp.o] Error 1 > make[1]: *** [common/CMakeFiles/common.dir/all] Error 2 > make: *** [all] Error 2 branch testing is now ready for testing. Sorry about that. I do not regularly test the 8 bit character (utf8) build. So I appreciate the report, and the testing. 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] Compiling probems
On 12/28/2010 02:25 AM, Martin wrote:
> dsnlexer is OK now.
> There are some other problems...
>
> (build 2690 on PCLinuxOS 2010)
>
> /home/martin/kicad/common/richio.cpp: In member function ‘virtual
> unsigned int FILE_LINE_READER::ReadLine()’:
> /home/martin/kicad/common/richio.cpp:116: error: call of overloaded
> ‘IO_ERROR(const wxChar*)’ is ambiguous
> /home/martin/kicad/include/kicad_exceptions.h:50: note: candidates are:
> IO_ERROR::IO_ERROR(const std::string&)
> /home/martin/kicad/include/kicad_exceptions.h:45: note:
> IO_ERROR::IO_ERROR(const wxString&)
> /home/martin/kicad/common/richio.cpp: In member function ‘virtual
> unsigned int STRING_LINE_READER::ReadLine()’:
> /home/martin/kicad/common/richio.cpp:167: error: call of overloaded
> ‘IO_ERROR(const wxChar*)’ is ambiguous
> /home/martin/kicad/include/kicad_exceptions.h:50: note: candidates are:
> IO_ERROR::IO_ERROR(const std::string&)
> /home/martin/kicad/include/kicad_exceptions.h:45: note:
> IO_ERROR::IO_ERROR(const wxString&)
> /home/martin/kicad/common/richio.cpp: In member function ‘virtual const
> char* OUTPUTFORMATTER::Quoted(std::string*)’:
> /home/martin/kicad/common/richio.cpp:306: error: call of overloaded
> ‘IO_ERROR(const wxChar*)’ is ambiguous
> /home/martin/kicad/include/kicad_exceptions.h:50: note: candidates are:
> IO_ERROR::IO_ERROR(const std::string&)
> /home/martin/kicad/include/kicad_exceptions.h:45: note:
> IO_ERROR::IO_ERROR(const wxString&)
> /home/martin/kicad/common/richio.cpp: In member function ‘virtual void
> STREAM_OUTPUTFORMATTER::write(const char*, int)’:
> /home/martin/kicad/common/richio.cpp:364: error: call of overloaded
> ‘IO_ERROR(const wxChar*)’ is ambiguous
> /home/martin/kicad/include/kicad_exceptions.h:50: note: candidates are:
> IO_ERROR::IO_ERROR(const std::string&)
> /home/martin/kicad/include/kicad_exceptions.h:45: note:
> IO_ERROR::IO_ERROR(const wxString&)
> make[2]: *** [common/CMakeFiles/common.dir/richio.cpp.o] Error 1
> make[1]: *** [common/CMakeFiles/common.dir/all] Error 2
> make: *** [all] Error 2
>
> greetings
>
> Martin Kratoska
Martin,
Either your compiler is at a different version than mine, or you have a
different wxWidgets version or character type (i.e. string type).
1) Please let me know what
$ wx-config --libs
says. For example if I run a version of wx-config against a wxWidgets
compiled with --disable-unicode, I get:
$ /opt/wx2.8-utf8/bin/wx-config --libs
-L/opt/wx2.8-utf8//lib -pthread -lwx_gtk2_xrc-2.9 -lwx_gtk2_html-2.9
-lwx_gtk2_qa-2.9 -lwx_gtk2_adv-2.9 -lwx_gtk2_core-2.9 -lwx_base_xml-2.9
-lwx_base_net-2.9 -lwx_base-2.9
2) Try the attached patch.
If it works, you can run with this patch for a few days.
The testing branch is going to be very dynamic for the next little bit (~2
weeks or so) (but that is a good thing).
Dick
--- /svn/kicad/testing.checkout/include/kicad_exceptions.h 2010-12-27 23:36:14.0 -0600
+++ include/kicad_exceptions.h 2010-12-28 07:26:49.0 -0600
@@ -42,6 +42,15 @@
{
wxStringerrorText;
+/**
+ * Constructor ( const wxChar* )
+ * handles the case where _() is passed as aMsg.
+ */
+IO_ERROR( const wxChar* aMsg ) :
+errorText( aMsg )
+{
+}
+
IO_ERROR( const wxString& aMsg ) :
errorText( aMsg )
{
___
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] Compiling probems
> 1) Please let me know what > > $ wx-config --libs Martin, wx-config --list seems better output. ___ 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] Sweet parser
Wayne, You had said that you would want to write the Sweet parser. Wayne's World: = I now have all the /new infrastructure in place to load Sweet strings driven by test program test_sch_lib_table. If you were to mostly confine yourself to basically that one function, PART::Parse() for now, we could now work in parallel without stepping on each other. Steps to get a build of test_sch_lib_table working: 1) Generate the test input data by running script make-dir-lib-source-test-data.sh Edit it as wanted, understand the script. 2) $ cd /new 3) $ mkdir build 4) $ cd build 5) $ cmake -DCMAKE_BUILD_TYPE=Debug ../ 6) $ make 7) $ ./test_sch_lib_table The int main() function is in sch_lib_table.cpp. You can and should edit the (lib_table ) element to point to a different, more permanent directory than tmp. Coordinate this with an edit to make-dir-lib-source-test-data.sh. The currently loaded part is "meparts:tigers/ears/rev10" at line 410 of sch_lib_table.cpp. You can edit the file tigers/ears.part.rev10 with a text editor and build up your input for the parser. If you need more help or don't want to do this anymore, please let me know. I have raced to get to this point, and will be going back over some things that need better robustness either way, especially in the area of error reporting, not so much functionality. sch_part.h has the new "contains" field we talked about, along with PB() and PartBits. You should even be able to write Inherits() as you get to that point. Inherits() will only ever be called from Parse(). The Parse() function is in sch_part.cpp, and I just took it far enough get you a playground. I am here to help. Thanks! Dick Copying the mailing list 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] Sweet parser
On 12/30/2010 12:18 PM, Wayne Stambaugh wrote: > On 12/29/2010 9:06 PM, Dick Hollenbeck wrote: >> Wayne, >> >> You had said that you would want to write the Sweet parser. >> >> Wayne's World: >> = >> >> I now have all the /new infrastructure in place to load Sweet strings driven >> by test >> program test_sch_lib_table. If you were to mostly confine yourself to >> basically that one >> function, PART::Parse() for now, we could now work in parallel without >> stepping on each other. >> >> Steps to get a build of test_sch_lib_table working: >> >> 1) Generate the test input data by running script >> make-dir-lib-source-test-data.sh >> Edit it as wanted, understand the script. >> >> 2) $ cd /new >> 3) $ mkdir build >> 4) $ cd build >> 5) $ cmake -DCMAKE_BUILD_TYPE=Debug ../ >> 6) $ make >> 7) $ ./test_sch_lib_table >> >> The int main() function is in sch_lib_table.cpp. >> >> You can and should edit the (lib_table ) element to point to a different, >> more permanent directory than tmp. >> Coordinate this with an edit to make-dir-lib-source-test-data.sh. >> >> The currently loaded part is "meparts:tigers/ears/rev10" at line 410 of >> sch_lib_table.cpp. >> >> You can edit the file tigers/ears.part.rev10 with a text editor and build up >> your input for the parser. >> >> If you need more help or don't want to do this anymore, please let me know. >> I have raced to get to this point, and will be going back over some things >> that need better robustness either way, especially in the area of error >> reporting, not so much functionality. > I've just started looking over what you've done yesterday and I'm still > trying to wrap my head around it. I will have some time over the next > few days but it will likely be a while before I can finish the task. If > it's something you can knock quickly, I would not be offended if you did it. > > I have attached the latest sweet specification which includes the name > hint and router pin and swap flags that we discussed before Christmas. > I'm not terribly thrilled about using route as part of the token name. > It seems a bit restrictive. There may be other tools that could take > advantage of pin and/or gate swapping. Maybe hint_pin_swap would be > more flexible and descriptive than route_pin_swap. Thanks. In light of the fact that I only have a tight time slot to work on this, another few days, I wonder if it would be a good idea for me to just do the basic parser, cherry picking the important items such as: 1) inheritance. 2) basic drawables probably not pins for lack of time, and the object action enhancements can be done by you later, since that requires having paid more attention during earlier conversations, than I did. For the next 2 hours or so I am rethinking the exception bucket a little bit, so up at the UI we can get precise information on all problems. That has been my driver since day one, and I don't want to go further until the foundation is rock solid. If something goes wrong, you should be able to tell, where, why, and what. >> sch_part.h has the new "contains" field we talked about, along with PB() and >> PartBits. You should even be able to write Inherits() as you get to that >> point. Inherits() will only ever be called from Parse(). > Were you thinking about creating new objects for all of the library part > drawable items or reusing the existing ones? I was hoping to reuse the > existing ones to ease migration to the new format and avoid creating an > external tool to convert existing libraries. I was thinking about > overriding the Save method for the library and all the LIB_ITEM objects > and adding a compile time option to the library editor to save the > libraries to the new format. That would give us some complete libraries > to work with. The new PART class will have a Format() function. I think it would be easiest to create a new front end to new PART, say an alternative parser that reads the old parts. It could even be made into a formal LIB_SOURCE, one which would dynamically convert old parts to the new API. In any case, I think it would be prudent to push all the old data though a new PART object, just to make sure it is convertible, then use the new PART::Format() function to output it, say back to a new library source, for which a person could even use DIR_LIB_SINK to do that. By tying a LIB_SOURCE to a non-matching LIB_SINK, you effectively get a conversion program, if you simply iterate over all parts. Well that sounded better than it will be, only because there is only one LIB_SINK planned by me, DIR_LIB_SIN
Re: [Kicad-developers] Sweet parser
On 12/30/2010 12:18 PM, Wayne Stambaugh wrote: > On 12/29/2010 9:06 PM, Dick Hollenbeck wrote: >> Wayne, >> >> You had said that you would want to write the Sweet parser. >> >> Wayne's World: >> = >> >> I now have all the /new infrastructure in place to load Sweet strings driven >> by test >> program test_sch_lib_table. If you were to mostly confine yourself to >> basically that one >> function, PART::Parse() for now, we could now work in parallel without >> stepping on each other. >> >> Steps to get a build of test_sch_lib_table working: >> >> 1) Generate the test input data by running script >> make-dir-lib-source-test-data.sh >> Edit it as wanted, understand the script. >> >> 2) $ cd /new >> 3) $ mkdir build >> 4) $ cd build >> 5) $ cmake -DCMAKE_BUILD_TYPE=Debug ../ >> 6) $ make >> 7) $ ./test_sch_lib_table >> >> The int main() function is in sch_lib_table.cpp. >> >> You can and should edit the (lib_table ) element to point to a different, >> more permanent directory than tmp. >> Coordinate this with an edit to make-dir-lib-source-test-data.sh. >> >> The currently loaded part is "meparts:tigers/ears/rev10" at line 410 of >> sch_lib_table.cpp. >> >> You can edit the file tigers/ears.part.rev10 with a text editor and build up >> your input for the parser. >> >> If you need more help or don't want to do this anymore, please let me know. >> I have raced to get to this point, and will be going back over some things >> that need better robustness either way, especially in the area of error >> reporting, not so much functionality. > I've just started looking over what you've done yesterday and I'm still > trying to wrap my head around it. I will have some time over the next > few days but it will likely be a while before I can finish the task. If > it's something you can knock quickly, I would not be offended if you did it. > > I have attached the latest sweet specification which includes the name > hint and router pin and swap flags that we discussed before Christmas. > I'm not terribly thrilled about using route as part of the token name. > It seems a bit restrictive. There may be other tools that could take > advantage of pin and/or gate swapping. Maybe hint_pin_swap would be > more flexible and descriptive than route_pin_swap. > >> sch_part.h has the new "contains" field we talked about, along with PB() and >> PartBits. You should even be able to write Inherits() as you get to that >> point. Inherits() will only ever be called from Parse(). > Were you thinking about creating new objects for all of the library part > drawable items or reusing the existing ones? I was hoping to reuse the > existing ones to ease migration to the new format and avoid creating an > external tool to convert existing libraries. I was thinking about > overriding the Save method for the library and all the LIB_ITEM objects > and adding a compile time option to the library editor to save the > libraries to the new format. That would give us some complete libraries > to work with. Wayne, This last paragraph makes me curious about something, and whether we are on the same page as to the degree to which this new API affects EESCHEMA. Really this whole discussion is about an API, and Sweet is literally part of the API because it is what is returned from the API. Although you COULD augment existing EESCHEMA to write Sweet files, it becomes nothing more than a conversion program at that point (but perhaps a decent conversion program). Old EESCHEMA will not be able to use the new API because: The API owns all the PARTs, it only lets the schematic reference them within the LIB cache. And then there is the parts list. So EESCHEMA will need to be rewritten in effect, at least 60% of it. This is my perspective. (And any time we talk about augmenting the existing code, I will begin to wonder why, I will question why.) Basically email is starting to suck for this. We may need to open up an IRC or use skype if it gets any more involved. 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] Sweet parser
> I think I have a decent understanding of how the API interfaces with > EESchema. I can see how the classes fit together to create the part > library API. I guess I'm thinking of what happens after the part library > API is loaded by EESchema. How do the parts get drawn? Where are the > arcs, circles, lines, etc. objects that are part of a SCH_PART reside? > We already have these objects that are fairly robust if less than > optimally designed (I'm working on that). Maybe I'm thinking too far > ahead or am missing something. They go into the PART of course. I was going to try out the GAL, and we had agreement on the dimenionless coordinate system, where the pin to pin distance is one unit. So I will try and re-use what we have for those drawables where it makes sense, and I may only get to a few of them before Monday. TEXT is a big point of departure, since we have that separate EFFECTs concept. I just completed a IO_ERROR() and PARSE_ERROR() upgrade, and now can capture the call site info of : __FILE_ __func__ and __LINE__ through what was a fairly brutal trial and error effort. To get these you have to use the macros THROW_IO_ERROR() and THROW_PARSE_ERROR(). When catching it seems we can catch either with catch( IO_ERROR& ioe ) which works for both only if caught *by reference* only. If your compiler does not support __func__, richio.h may have to be doctored until we get some ifdefs in there. >> Although you COULD augment existing EESCHEMA to write Sweet files, it >> becomes nothing more than a conversion program at that point (but perhaps a >> decent conversion program). > I think that is something most users will want. Using a script or > external program to convert from the current file format is something > most users will frown upon. > >> >> Old EESCHEMA will not be able to use the new API because: >> >> The API owns all the PARTs, it only lets the schematic reference them within >> the LIB cache. And then there is the parts list. So EESCHEMA will need to >> be rewritten in effect, at least 60% of it. > I order for this to happen we will need to start defining the new > schematic file format. I don't think mixing the existing file format > with sweet would get rather ugly. I can start putting together a > preliminary schematic file specification over the next month or so. Very true. There is a lot of work that can be done from ground up, for quite a while yet. The textual part editor and the parts list UI panel could stand alone on top of the code we now have. Before the parts list UI is done, we should not place any large bets. That is the riskiest portion of the design. The spreadsheet view will have to be able to come into the PARTS_LIST and jam the desired set of FIELDS/PROPERTIES down the throat of all the PARTS in the PARTS_LIST, so they all have the same columns. So this will be one of software engineering's finest hours if we can pull it off. It may have to be one with a facade of some kind. Happy New Year to everyone. >> This is my perspective. (And any time we talk about augmenting the existing >> code, I will begin to wonder why, I will question why.) >> >> Basically email is starting to suck for this. We may need to open up an IRC >> or use skype if it gets any more involved. > I have neither a Skype nor an IRC account but it won't take long to > create one or both. If (when?) we get to that point, let me know which > medium you prefer and I will get it set up. > > Wayne Let's keep it in mind, especially if we are active at the same points in time. 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] Sweet parser
Wayne, I just made a commit that fixes some minor issues to a commit I made last night, and I can now see the inheritance mechanism working really pretty well. Today is a company holiday I was not aware of, so that gives me another day to work on this stuff in an active mode. My normal mode would be more intermittent, or weekend centric, than what I can spend on it today. I will make another commit very late this evening, and then take a less active role for the remainder of the week, which could give you some time on it. = Units: My thinking is that we do not have units, but if you wanted to name them they might be: "pin intervals", "pin spaces", or "pin deltas", which means of course, the standard minimum distance between two pins in the new EESCEMA. A value of 1 pin delta is what you'd often see in the Sweet strings, *between* pins, in either X or Y axes. = Internal Units: Do we want integers, floats, or doubles. (Haven't looked at the GAL yet to see what it likes.) If integers, then we need some internal unit. My suggestion there would be to use 1000 pin deltas. This would give us the granularity to position within a 1/1000th of a normal minimum pin delta. And would give us the ability on the high end to go 4 billion (int32_t) / 1000 = 1 million pins per X or Y axis. This way we simply multiple the Sweet strings coordinates by 1000 as we parse them into internal units. 1 would also be reasonable, if you wanted to position something between pins within 1/1th of a pin delta. What do folks think? 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] Sweet parser
On 01/03/2011 01:58 PM, Dick Hollenbeck wrote: > Wayne, > > I just made a commit that fixes some minor issues to a commit I made last > night, and I can now see the inheritance mechanism working really pretty well. > > Today is a company holiday I was not aware of, so that gives me another day > to work on this stuff in an active mode. My normal mode would be more > intermittent, or weekend centric, than what I can spend on it today. > > I will make another commit very late this evening, and then take a less > active role for the remainder of the week, which could give you some time on > it. > > = > > Units: > > My thinking is that we do not have units, but if you wanted to name them > they might be: > > "pin intervals", "pin spaces", or "pin deltas", which means of course, the > standard minimum distance between two pins in the new EESCEMA. > > A value of 1 pin delta is what you'd often see in the Sweet strings, > *between* pins, in either X or Y axes. > > > = > > Internal Units: > > Do we want integers, floats, or doubles. (Haven't looked at the GAL yet to > see what it likes.) If integers, then we need some internal unit. > > My suggestion there would be to use 1000 pin deltas. oops, I meant: My suggestion there would be to use 1/1000th of a pin delta as the internal unit. > This would give us the granularity to position within a 1/1000th of a normal > minimum pin delta. And would give us the ability on the high end to go > > 4 billion (int32_t) / 1000 = 1 million pins per X or Y axis. > > This way we simply multiple the Sweet strings coordinates by 1000 as we > parse them into internal units. > > 1 would also be reasonable, if you wanted to position something between > pins within 1/1th of a pin delta. > > What do folks think? > > 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 12/14/2010 07:19 AM, "Torsten Hüter" wrote: > Hi Dick, > > thanks, I'll add this patch. > I'm doing a lot of restructuring at the moment and write a small demo to test > the functions for rubberbanding - have not yet commited. I think I should be > ready this or next weekend with the rubberbanding test and then I'll commit > and open the repository for write access. > > Bye .. > Torsten Torsten, Is this still on your to do list? Some minor suggestions for improvements: 1) Also, std::list should be changed to std::deque wherever it is being used. std::list is too slow for several reasons: a separate heap allocation must happen just to store the separate linked list backbone noes, per content node. That linkedlist node must store a pointer to real content node, slowing down again the traversal, due to the dereferencing of the linked-list node pointer. Heap allocation is by far the slowest issue. You have twice as many in a std::list, I will use std::deque. Its ten minutes to change it. 2) I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does not provide enough value for the costs: 1) obscurity about what code it is actually generating. 2) longer compile times. Suggest simply writing the 3 statements that the macro is replacing, so we see what the compiler sees. Again, I will need write access to this repo, if I am going to use it. I was thinking of using it for a simple Sweet viewer. Of course I can always make my own copy of the repo and make it public, thanks to your generosity of contributing this code under the GPL. If you are too busy, let me know and I will do these items myself. 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] Sweet parser
On 01/03/2011 03:59 PM, Wayne Stambaugh wrote: > On 1/3/2011 3:36 PM, Dick Hollenbeck wrote: >> On 01/03/2011 01:58 PM, Dick Hollenbeck wrote: >>> Wayne, >>> >>> I just made a commit that fixes some minor issues to a commit I made last >>> night, and I can now see the inheritance mechanism working really pretty >>> well. >>> > Dick, > > I've attached the changes I made to the library part file specification last > night. I updated all of the coordinates for dimensionless units. All I did > was divide all of the coordinates by 50 (mils). Beautiful. >I added a short blurb about > logical coordinates. "pin cell" is another name that came to mind, again like drawing pins on graph paper. Logical coordinates are fine too, but requires more intellectual energy to understand IMO. Having more than one way to describe the concept is good, whatever we can can stack up to convey the concept, and it may require a couple of different approaches for folks to understand. Logical coordinates are a fine approach. I just wouldn't start there with my Mom. I would start with graph paper and the notion of a pin cell, which is the same as what she sees on the graph paper. > I also renamed route_pin_swap and route_alt_swap to > hint_pin_swap and hint_alt_swap. I think route is too tool specific. A > hinting system that is tool agnostic makes more sense to me. > >>> Today is a company holiday I was not aware of, so that gives me another day >>> to work on this stuff in an active mode. My normal mode would be more >>> intermittent, or weekend centric, than what I can spend on it today. > Always a nice surprise. > >>> I will make another commit very late this evening, and then take a less >>> active role for the remainder of the week, which could give you some time >>> on it. > I'll start messing around with it tonight as I have some to kill tonight. > >>> = >>> >>> Units: >>> >>> My thinking is that we do not have units, but if you wanted to name them >>> they might be: >>> >>> "pin intervals", "pin spaces", or "pin deltas", which means of course, the >>> standard minimum distance between two pins in the new EESCEMA. >>> >>> A value of 1 pin delta is what you'd often see in the Sweet strings, >>> *between* pins, in either X or Y axes. > I was thinking more in terms of logical units. All items that are connectible > (pins, wires, labels, etc.) must have integer units to guarantee connectivity. Well "must have" may be too strong. But we agree on the concept. The only reason to stray from this is to handle the case where an old part was just so poorly designed, and it needs to be converted, just to get it into a new editor environment. The coordinates may not be on a pin cell boundary. We can support fractional pin cells, but don't want to as a rule. > All non-connectible items (lines, text, etc.) can have non-integer units as > well. Any can have any. But on the assumption that everyone wants to conform, and create a maximally re-useable part, then everything should be on a pin cell boundary, including text. We can flash a red box on screen if someone doesn't want to wear the school uniform. > This way it doesn't matter internally what EESchema uses as it's > coordinate scalar other than making sure you don't overflow or underflow the > integer. Yes, the accumulation of Intellectual Property, is in the growing body of Sweet specs. This is our goal, and I think it has the potential to transcend Kicad. If we do this right, then this thing will be adopted outside Kicad, no question. We will take a bow when some part vendor provides a Kicad library in Sweet form, and puts it up using HTTP_LIB_SOURCE. 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
On 01/03/2011 05:26 PM, "Torsten Hüter" wrote: > Hi Dick, > >> Is this still on your to do list? > Yes, of course, I just had not the time that I thought I would have and the > example grows also bigger than expected .. > >> Some minor suggestions for improvements: >> >> 1) >> >> Also, std::list should be changed to std::deque wherever it is being used. >> std::list is too slow for several reasons: >> a separate heap allocation must happen just to store the separate linked >> list backbone noes, per content node. >> That linkedlist node must store a pointer to real content node, slowing >> down >> again the traversal, due to the dereferencing of the linked-list node >> pointer. >> Heap allocation is by far the slowest issue. You have twice as many in a >> std::list, I will use std::deque. Its ten minutes to change it. > Yes, I agree - this was just an initial choice - I've changed some types > already to std::vector but the std::deque is also a good idea. > >> 2) >> >> I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does >> not provide enough value for the costs: >> >> 1) obscurity about what code it is actually generating. >> >> 2) longer compile times. >> >> Suggest simply writing the 3 statements that the macro is replacing, so we >> see what the compiler sees. > The Eclipse CDT formatter has also a lot trouble with it. Good suggestion. > >> Again, I will need write access to this repo, if I am going to use it. I >> was thinking of using it for a simple Sweet viewer. Of course I can >> always >> make my own copy of the repo and make it public, thanks to your generosity >> of contributing this code under the GPL. If you are too busy, let me know >> and I will do these items myself. > Shouldn't take much time, I've changed only the directory structure a lot - > I'll upload it in the next days. > > Bye .. > Torsten You da man! std::vector is better than std::list. std::deque and std::vector are both OK. The only difficulty with std::vector is if you hundreds of thousands of points in a polyline, in which case the backbone array needs to be very large. std::deque uses a segmented backbone, and could be slower than std::vector for smaller numbers of points. So std::vector is fine if you are already there. Thank you. 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
>> 2) >> >> I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does >> not provide enough value for the costs: >> >> 1) obscurity about what code it is actually generating. >> >> 2) longer compile times. >> >> Suggest simply writing the 3 statements that the macro is replacing, so we >> see what the compiler sees. > The Eclipse CDT formatter has also a lot trouble with it. Good suggestion. Another benefit there is I think you can then remove the findboost from the CMakeLists.txt file. I did a grep and it is the only boost dependency you have. (boost is fine, but asking the user to tell you where it is comes at a cost to the user. The benefit is not there for this.) 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] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
You have twice as many in a
>>> std::list, I will use std::deque. Its ten minutes to change it.
>> Yes, I agree - this was just an initial choice - I've changed some types
>> already to std::vector but the std::deque is also a good idea.
>>
> std::vector is better than std::list. std::deque and std::vector are both
> OK. The only difficulty with std::vector is if you hundreds of thousands of
> points in a polyline, in which case the backbone array needs to be very
> large. std::deque uses a segmented backbone, and could be slower than
> std::vector for smaller numbers of points.
Well even for relatively smaller numbers of POINTS, say 5000, std::deque is
faster than even std::vector. Here are the results of a test program I
wrote which uses push_back() against all 3 types of lists:
std::list, std::vector, and std::deque. Even at 5000 elements, deque wins
hands down. Try it at larger counts, test program attached.
$./test_lists
list duration: 828673
vector duration: 198271
deque duration: 123940
The times are in nanoseconds.
The test program is attached if you want to play with it.
std::deque needs more consideration than what I said in my last email. I
think the difference will be even more pronounced as the complexity of the
contained object becomes more pronounced, since std::vector must copy all
the objects to the expanded array as it grows. Makes me wonder if you
should loose the
virtual ~VECTOR2
Just let anyone deriving from VECTOR2<> add in virtual destructors, you
don't need it at this level. It causes the virtual function table to be
copied and constructed, both of which cost time, for large numbers of points.
Dick
/* Test the speed of insertion into 3 kinds of lists:
std::list, std::vector, std::deque
*/
#include
#include
#include
#include
#include
#include
unsigned GetRunningNSecs()
{
struct timespec now;
clock_gettime( CLOCK_MONOTONIC, &now );
uint64_t nsecs = now.tv_nsec + now.tv_sec * uint64_t(1000*1000*1000);
return unsigned( nsecs );
}
struct POINT
{
int x;
int y;
};
#define APPEND_COUNT5000
//#define APPEND_COUNT10
int main( int argc, char** argv )
{
std::listmylist;
std::vector myvector;
std::deque mydeque;
unsigned start = GetRunningNSecs();
for( int i=0; i___
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] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)
> It causes the virtual function table pointer > to be > copied and constructed, both of which cost time, for large numbers of points. > > > Dick Its only another pointer, but its one you don't need in the object at this level. ___ 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] Sweet parser
>>> This would give us the granularity to position within a 1/1000th of a normal >>> minimum pin delta. And would give us the ability on the high end to go >>> >>> 4 billion (int32_t) / 1000 = 1 million pins per X or Y axis. > I don't know if there would be a significant performance hit using 64 bit > integers on 32 bit systems. I doubt it would be much of an issue for > EESchema. > Also, don't define it as an int32_t. Otherwise, it won't build on MSVC as > stdint.h is not defined. Use wxInt32 instead. I learned this one the hard > way. > > Wayne More of the MSVC shit. Don't expect me to care. I may contribute without regard for MSVC. Think of my contributions as targeted charitable contributions. I would prefer not to hear about MSVC again. I will not give it any consideration. Thank you, 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] CMake's ExternalProject Support
http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html http://www.cmake.org/cmake/help/cmake-2-8-docs.html#module:ExternalProject I was recently surprized by the power of the CMake ExternalProject support. I have used it once for something very simple, but I obviously mis-judged the depth of support that is there. It seems very extensive on second reading. This may be of interest to Windows or MAC developers who need an external library and cannot be sure it is there, without something like this to go get it and make it happen. Clearly there is some advantage to having a single driver program (CMake) tie all the pieces together. 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] [PATCH] Saving plot dialog settings
> The previous patch has a bug. It incorrectly complains about no layers > being selected. This patch works better. > > marco > > On Sun, Jan 2, 2011 at 11:40 PM, Marco Mattila wrote: >> Hi, >> >> During previous discussions about subtracting masks from silkscreen >> layers when plotting gerbers, Dick mentioned that saving plot settings >> is not quite up to date. Currently some plot settings to be >> saved/loaded are defined in pcbnew_config.cpp. However, that requires >> that corresponding variables in the PCB_PLOT_PARAMS class are public. >> My proposal is to let the class itself take care of saving/loading the >> settings. That's mainly what the attached patch changes. In addition, >> all plot dialog settings should now be included. The wxConfig key >> names are also edited to start with "Plot", and layer selections are >> combined into a single bit mask. Moreover, some global variables in >> pcbplot.cpp have been moved into the class, too. g_PcbPlotOptions >> itself is still global. However, I think that it could be moved to be >> a member of the WinEDA_BasePcbFrame. That way it should be accessible >> where needed without being global. And if necessary, plot settings >> could still be loaded only once when pcbnew starts (now they are >> loaded every time the plot dialog constructor is called). In addition >> drill file generation settings could be included into PCB_PLOT_PARAMS. >> I can continue working on this if my approach sounds reasonable. >> >> marco I would say the patch looks like an improvement worth committing. Thanks. If anyone has concerns they should voice them. This little bit here is goofy though, for a function comment: PCB_PLOT_PARAMS(); +/** + Function LoadSettings + loads plot settings from wxConfig system. + @param aConfig is a pointer to a wxConfig. + */ +voidLoadSettings( wxConfig* aConfig ); +/** + Function SaveSettings + saves current plot settings to wxConfig system. + @param aConfig is a pointer to a wxConfig. + */ +void In the future, please leave a space between these like the coding standard says, and fill in the vertical stars. My vote is to commit. 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] [PATCH] Saving plot dialog settings
On 01/05/2011 07:47 AM, Marco Mattila wrote: > Damn. I always struggle the most with the comments for Doxygen... > > I think that we may be able to get rid of the global variable. I'll > take a look. I'll fix the comments in the next patch, too. > > marco >From a usability standpoint, i.e. user experience, I have a concern about saving the desired layers, as if I was only ever going to work on one board. Now that you have a compact bitmap, would it make sense to prefix the Config key for layers, with the boardname? Although this might eventually pollute the configuration space, you'd have to do a lot boards to get there. This way it remembers what layers you want for what boards. The idea would be to put this information in the board, no preference here. Is this anything worth considering? 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
