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
11 matches
Mail list logo
