> 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;
type
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 me
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
>> 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 ball
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
Pos
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
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 th
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 differe
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 als
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
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 2
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 th
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 includ
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 includ
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:
>>>
>>>
>>>
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
>>> )
>>&
___
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
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
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 fo
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
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
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
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:
>>>
>>>
&g
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 th
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
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 I
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://la
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
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 crea
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.l
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
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 w
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 defin
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 every
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_lin
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
> footprin
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 area
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
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 gerb
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:
t; 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
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 le
> 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.
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
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
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 remai
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
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
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
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
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
>
> 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
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 altern
>> 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
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 B
> 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
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 Stambaug
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 pa
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:
>>>
>> 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, rectan
> 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
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 us
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
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
>>>> -
> 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 thes
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
> 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
>
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 p
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 p
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/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:
>>>>&g
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 i
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
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
t
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 conv
| 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
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 a
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 d
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. Fir
(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 wha
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:
>
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:
>
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: c
> 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
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() f
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 in
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 in
> 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
> arc
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 woul
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 gi
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 rubberba
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
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)
>>
>>
>> 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 macr
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
> 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:
>>> 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 6
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 mi
> 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,
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 ex
1 - 100 of 2259 matches
Mail list logo
