Wayne,
Attached is a patch against TokenList2DsnLexer.cmake that I would like
to commit.
The script takes an additional *optional* parameter named "enum" which
if provided will give the name of the enum which is declared. It seemed
like if multiple generated headers were included into a single s
Ok I've started (as I get spare time throughout the day) working my way
through the imported bugs. I'll mark the ones I'm closing as incomplete so
they can expire.
What do you want me to do with bugs that have attached patches? As they
have been patched against sourceforge SVN are they stil
[ Belatedly changed the subject, to look better in that thread
hijacking trial. ]
Thanks for your description. Now I understand better where those
"heavy symbols" come from. Okay, not crazy. Not at all. But still
flawed ;-)
I agree that CPNs make things a lot easier, but managing them also
has
to the
following page to enter your feedback:
https://answers.edge.launchpad.net/malone/+question/106874
You received this question notification because you are a direct
subscriber of the question.
__ Information from ESET Smart Security, version of virus signature
database 5196 (20
Werner Almesberger wrote:
Wayne Stambaugh wrote:
I like being able to embed this information into my schematics.
I'm still puzzled what you're doing where this approach wouldn't
turn into a nightmare before too long :)
Good points - but - to share some experience over some decades of using c
Hi All,
Dick, your improvement makes a lot of sense. I think I'm right in
thinking that what my patch would do in the case of importing a 3rd
party library would be to import the field names from that library,
without adding the template field names . Being able to add the
template field names on
On 06/14/2010 12:42 PM, Werner Almesberger wrote:
> Dick Hollenbeck wrote:
>
>> You seem to be especially concerned about a manufacturer field within
>> the symbol becoming obsolete.
>>
> Yes, or the field having an almost arbitrary value from a vast
> set, e.g., in the "any 100 k resistor"
On 06/14/2010 12:05 PM, Werner Almesberger wrote:
> Dick Hollenbeck wrote:
>
>> You have good reading comprehension.
>>
> Heh, thanks :-)
>
>
>> "template" aka "wanted", not "wanted" aka "template". The distinction
>> is important since I have started coding it, and the source reflects
Dick Hollenbeck wrote:
> You seem to be especially concerned about a manufacturer field within
> the symbol becoming obsolete.
Yes, or the field having an almost arbitrary value from a vast
set, e.g., in the "any 100 k resistor" case.
> But for the mean time WRT template fieldnames, you are not r
Dick Hollenbeck wrote:
> You have good reading comprehension.
Heh, thanks :-)
> "template" aka "wanted", not "wanted" aka "template". The distinction
> is important since I have started coding it, and the source reflects the
> latter term.
Good. I like "template" much better than "wanted" as we
On 06/14/2010 10:18 AM, Werner Almesberger wrote:
> Wayne Stambaugh wrote:
>
>> I like being able to embed this information into my schematics.
>>
> I'm still puzzled what you're doing where this approach wouldn't
> turn into a nightmare before too long :)
>
> Let's see. If you have multipl
Wayne Stambaugh wrote:
> I like being able to embed this information into my schematics.
I'm still puzzled what you're doing where this approach wouldn't
turn into a nightmare before too long :)
Let's see. If you have multiple instances of the same component,
let's say the ubiquitous 100 kOhm 5%
On 06/14/2010 06:59 AM, Werner Almesberger wrote:
> Dick Hollenbeck wrote:
>
>> [...] "Installed" (e.g. value=DNS) [...]
>>
> What would you think of elevating "Installed" (or whatever it
> would be called in the end) to the rank of Footprint ? I.e., a
> permanent field with an immutable na
On 06/14/2010 04:39 AM, Werner Almesberger wrote:
Werner,
You have good reading comprehension. I make only a few clarifications
below.
> Let me see if I got all the bits in your description:
>
> "default" field names:
> - are hard-coded (or equivalent) into KiCad,
> - can be overridden by "want
Original Message
Subject:Re: [Question #106874]: Please convert bug database from
sorurceforge.net
Date: Mon, 14 Jun 2010 13:50:57 -
From: Graham Binns
Reply-To: question106...@answers.launchpad.net
To: d...@softplc.com
Your question #106874 on Laun
On 6/14/2010 5:39 AM, Werner Almesberger wrote:
> Let me see if I got all the bits in your description:
>
> "default" field names:
> - are hard-coded (or equivalent) into KiCad,
> - can be overridden by "wanted" or "user-defined" field names.
>
> "wanted" aka "template" field names:
> - are assig
On 6/14/2010 12:14 AM, Dick Hollenbeck wrote:
> On 06/13/2010 07:30 PM, Wayne Stambaugh wrote:
>> On 6/13/2010 4:24 PM, Dick Hollenbeck wrote:
>>
>>> On 06/10/2010 04:35 AM, Brian Sidebotham wrote:
>>>
> Thanks for handling this. I probably wouldn't be able to get to it for
> at le
On Mon, 14 Jun 2010, Werner Almesberger wrote:
Hmm, but if you use it mainly for rework, adjacent components could
share the courtyard, no ? After all, you'll inspect or (de)solder
them one by one, not simultaneously.
It would be difficult to say 'how much' they can overlap... I think they
cal
Dick Hollenbeck wrote:
> [...] "Installed" (e.g. value=DNS) [...]
What would you think of elevating "Installed" (or whatever it
would be called in the end) to the rank of Footprint ? I.e., a
permanent field with an immutable name.
That way, eeschema could automaticaly flag absent components,
e.g.
Lorenzo Marcantonio wrote:
> Only another playground... its the "bounding tile" of the component,
Hmm, but if you use it mainly for rework, adjacent components could
share the courtyard, no ? After all, you'll inspect or (de)solder
them one by one, not simultaneously.
Also, what do you do with co
I wrote:
> What would constitute an invasion of the "playground" ?
BTW, here are some thoughts on clearance (for electrical reasons,
but much of this should also apply to mechanical clearance):
http://lists.openmoko.org/pipermail/gta02-core/2009-September/000583.html
Only the list at the beginnin
On Mon, 14 Jun 2010, Werner Almesberger wrote:
Lorenzo Marcantonio wrote:
The playground should be a simple bounding box, but manually defined
(since, for example, BGA requires a lot of tooling space for inspection
and replacement, while a simple MLCC only needs space for tweezers)
What would
Lorenzo Marcantonio wrote:
> The playground should be a simple bounding box, but manually defined
> (since, for example, BGA requires a lot of tooling space for inspection
> and replacement, while a simple MLCC only needs space for tweezers)
What would constitute an invasion of the "playground" ?
Let me see if I got all the bits in your description:
"default" field names:
- are hard-coded (or equivalent) into KiCad,
- can be overridden by "wanted" or "user-defined" field names.
"wanted" aka "template" field names:
- are assigned by a global (user-wide or even site-wide) configuration,
- a
Another thing while you're working on the module format:
It would be useful the so-called 'playground', i.e. a bounding box
comprising the required reworking space. It could be even used during
DRC for detecting overlapped components.
The playground should be a simple bounding box, but manually
25 matches
Mail list logo
