On 04/13/2012 08:31 PM, Dan Chianucci wrote:
And secondly, If there is a lone via
somewhere on the board (this can happen if the save file is manually
edited) the Zones do not connect to it even if they are in the same
net.
Hi Dan,
I noticed this while trying to port some of our designs to Kica
Glad to hear people use it. It's extremely low maintenance on my end--I
think I've spent less than 6 hours on it since I started it, which was at
least a year ago IIRC. It's quite an amazing service for Canonical to
offer for free, really.
Preliminary reports on my machine seem to show it workin
> wxRound may be overkill but it does one important thing that will become
> apparent when I commit the code that scales the PCB_SCREEN zoom factors
> to work properly with nanometer internal units. In debug builds,
> wxRound tests if the floating point result is within INT_MIN and INT_MAX
> and
Hi Dan,
I think you're not the first one talking about this on the list. Somebody
suggested doing it with tracks:
http://biro.wordpress.com/2011/11/25/stitching-layers-between-copper-zones-in-kicad/
Greetings!,
PS: I'm also used to work placing standalone vias to stich planes in other
ED
On 04/13/2012 01:27 PM, Adam Wolf wrote:
> Hi folks,
>
> Sorry about that! I pulled it from an existing recipe. It's on my todo
> list, but it
> was towards the bottom. It should be a 1 line change in the build recipe.
> I'll take a
> 10 minute look right now, and if it takes longer than that
wxRound()'s use of C lib's round() seems like overkill to me.
> wxRound may be overkill
>
> I did not say it was overkill. I said it can be making an unnecessary
> function call.
Well I guess I did say it was overkill, shit.
But you should listen to what I mean, not what I say!
:)
Ple
On 04/13/2012 02:03 PM, Dick Hollenbeck wrote:
> On 04/13/2012 12:00 PM, Wayne Stambaugh wrote:
>> On 4/13/2012 10:04 AM, Dick Hollenbeck wrote:
Also, you may want to
change Mils2iu to use wxRound() so it will work for negative values.
>>> wxRound()'s use of C lib's round() seems like ove
On 04/13/2012 12:00 PM, Wayne Stambaugh wrote:
> On 4/13/2012 10:04 AM, Dick Hollenbeck wrote:
>>> Also, you may want to
>>> change Mils2iu to use wxRound() so it will work for negative values.
>> wxRound()'s use of C lib's round() seems like overkill to me.
>> Since the objective is to produce an
I have a board that has a GND zone on the top and on the bottom.
Normally, I would connect the two zones in various places around the
board with vias. However, PCBNew does not support this functionality.
For one, a lone via cannot be placed onto the board if it is not
connected to a pad somehow. A
Hi folks,
Sorry about that! I pulled it from an existing recipe. It's on my todo
list, but it was towards the bottom. It should be a 1 line change in the
build recipe. I'll take a 10 minute look right now, and if it takes longer
than that, I can take a look at it this weekend.
If someone else
On 04/13/2012 10:18 AM, Wayne Stambaugh wrote:
> On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
>> On 04/13/2012 02:04 AM, jean-pierre charras wrote:
>>> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
On 4/13/2012 10:04 AM, Dick Hollenbeck wrote:
>> Also, you may want to
>> change Mils2iu to use wxRound() so it will work for negative values.
>
> wxRound()'s use of C lib's round() seems like overkill to me.
> Since the objective is to produce an integer, not a double, there is an
> easier way t
Adam and others,
What can be done so that the installed PPA package can show the correct BZR
version and date?
I'm thinking the BZR version is not being updated correctly, maybe a minor
tweak in the
PPA build recipe can fix this.
It is quite disorienting for a newbie.
Thanks,
Dick
On 4/13/2012 8:39 AM, Dick Hollenbeck wrote:
> On 04/13/2012 02:04 AM, jean-pierre charras wrote:
>> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
>>> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
On 04/11/2012 06:41 PM, Dan Chianucci wrote:
> This new format looks great, I have a few comm
On 04/13/2012 09:00 AM, Miguel Angel Ajo Pelayo wrote:
> Hi Dick thanks for the reply :-)
>
> 2012/4/13 Dick Hollenbeck
>> Hi Mike,
>>
>> Thanks for your time on this.
>
> I'm happy to do it.
>
>> [snip]
>>> 1) Added to new plugin types:
>> I don' think we don't need these 2 new enum values. Thi
> On 64-bit builds, integers are 64 bits so it becomes meaningless at that
> point. Even on 32 bit hardware, there are much more pressing issues
> that need to be resolved.
Knowing now that int is 32 bit on x86_64 under gcc, we should also know that
size_t is 64
bits.
This can be an issue when
> Also, you may want to
> change Mils2iu to use wxRound() so it will work for negative values.
wxRound()'s use of C lib's round() seems like overkill to me.
Since the objective is to produce an integer, not a double, there is an easier
way that
has the possibility of letting the compiler do some
2012/4/13 Dick Hollenbeck :
>>> c) There is the case of opening/saving single componente files
>>> (.cmp?), that would
>>> be almost the same plugin.
>> I don't want to support that, unless it can be done with the plugin with
>> special status,
>> which is the "KICAD" plugin, and I think thi
Hi Dick thanks for the reply :-)
2012/4/13 Dick Hollenbeck
>
> Hi Mike,
>
> Thanks for your time on this.
I'm happy to do it.
>[snip]
> >
> > 1) Added to new plugin types:
>
> I don' think we don't need these 2 new enum values. This support goes into
> LEGACY and
> KICAD plugins, respectiv
>> This is one of those areas where I am relying on the knowledge of
>> someone who know about the BOARD_ITEM internals that I do. If there is
> ^ knows more^ than
>
> I really need to get away from my computer :)
>
> Wayne
That will only make you worse at t
On 04/13/2012 08:41 AM, Dick Hollenbeck wrote:
>>> c) There is the case of opening/saving single componente files
>>> (.cmp?), that would
>>> be almost the same plugin.
I do see the case for loading the single shot foreign footprint, but not saving.
__
>> c) There is the case of opening/saving single componente files (.cmp?),
>> that would
>> be almost the same plugin.
> I don't want to support that, unless it can be done with the plugin with
> special status,
> which is the "KICAD" plugin, and I think this is simply
>
> SaveModule() on t
Hi Mike,
Thanks for your time on this.
I have some comments below.
> This is a first approach.
>
> It's what I understood from your last email, my idea was more complicated.
>
> summary:
>
> 1) Added to new plugin types:
I don' think we don't need these 2 new enum values. This support goes in
On 04/13/2012 02:32 AM, Solonen Vesa wrote:
>> Like so many suggestions, they are often good ideas that never get done,
>> because they do
>> not rise to a sufficient level of need within an individual capable of doing
>> the work.
>> This is especially true in free software, which in fact is nev
On 04/13/2012 02:04 AM, jean-pierre charras wrote:
> Le 12/04/2012 20:53, Wayne Stambaugh a écrit :
>> On 4/12/2012 9:05 AM, Dick Hollenbeck wrote:
>>> On 04/11/2012 06:41 PM, Dan Chianucci wrote:
This new format looks great, I have a few comments/questions
1) in some spots lik
This is a first approach.
It's what I understood from your last email, my idea was more complicated.
summary:
1) Added to new plugin types:
+LEGACY_LIBRARY, //< Legacy Pcbnew library file
format
+KICAD_LIBRARY, //< S-expression based library
form
> Like so many suggestions, they are often good ideas that never get done,
> because they do
> not rise to a sufficient level of need within an individual capable of doing
> the work.
> This is especially true in free software, which in fact is never free.
Feature bounties might be a workable s
27 matches
Mail list logo
