On Jun 3, 2011, at 2:09 AM, Peter Brett wrote:
> John Doty writes:
>
>> On Jun 1, 2011, at 7:58 PM, Peter Brett wrote:
>>
>>> John Doty writes:
>>>
On May 31, 2011, at 11:02 PM, Peter Brett wrote:
>>>
> This script deliberately poisons the netlist.
Exactly. This is cons
On Jun 3, 2011, at 12:08 AM, DJ Delorie wrote:
>>>
>>> The only reason we can't do that at the moment is that the file
>>> format doesn't support removing an attribute.
>>
>> I don't understand. (gnetlist:get-package-attribute) could easily
>> return '() or #f if you wish. What does the file fo
John Doty writes:
> On Jun 1, 2011, at 7:58 PM, Peter Brett wrote:
>
>> John Doty writes:
>>
>>> On May 31, 2011, at 11:02 PM, Peter Brett wrote:
>>
This script deliberately poisons the netlist.
>>>
>>> Exactly. This is consistent with other gnetlist behavior. If no
>>> attribute is fo
> > The only reason we can't do that at the moment is that the file
> > format doesn't support removing an attribute.
>
> I don't understand. (gnetlist:get-package-attribute) could easily
> return '() or #f if you wish. What does the file format have to do
> with this?
The *.sch file has no way
On Jun 1, 2011, at 7:58 PM, Peter Brett wrote:
> John Doty writes:
>
>> On May 31, 2011, at 11:02 PM, Peter Brett wrote:
>
>>> This script deliberately poisons the netlist.
>>
>> Exactly. This is consistent with other gnetlist behavior. If no
>> attribute is found, the resulting value is "u
John Doty writes:
>On May 31, 2011, at 11:02 PM, Peter Brett wrote:
>> This script deliberately poisons the netlist.
>
> Exactly. This is consistent with other gnetlist behavior. If no
> attribute is found, the resulting value is "unknown". So, I think
Yes, and that behaviour is broken too.
On May 31, 2011, at 11:02 PM, Peter Brett wrote:
The attached script not only emits a message, but substitutes
"attribute_conflict" for the attribute in question. Since that's not
normally a legitimate value, it should help the user to detect the
problem.
From my pe
> From my perspective, I don't understand why this is better. 1.7.0 warns
> about undefined behaviour, and defaults to backwards-compatibility
> (which makes some sense IMHO). This script deliberately poisons the
> netlist. In my ideal world (haha) gnetlist would generate errors on
> attribute
> The attached script not only emits a message, but substitutes
> "attribute_conflict" for the attribute in question. Since that's not
> normally a legitimate value, it should help the user to detect the
> problem.
>From my perspective, I don't understand why this is better. 1.7.0 warns
about un
John Doty wrote:
> Usage:
>
> gnetlist -m censor_fix.scm (other gnetlist args)
For use with gsch2pcb and a project file put censor_fix.scm to the local
path and call like this:
gsch2pcb --gnetlist-arg "-m censor-fix.scm" project.g2p
> based on feedback from Kai-Martin, here's an improved ver
Based on feedback from Kai-Martin, here's an improved version:
censor-fix.scm
Description: Binary data
On May 26, 2011, at 4:58 PM, John Doty wrote:
> Folks,
>
> The "attribute censorship bug" is what I call the problem that given a refdes
> that corresponds to multiple symbol instances, gn
Folks,
The "attribute censorship bug" is what I call the problem that given a refdes
that corresponds to multiple symbol instances, gnetlist only looks for
attributes from the first instance it finds, ignoring the rest. One common
place this causes trouble is in footprints for slotted component
12 matches
Mail list logo
