Fixes have been pushed. Let me know if they don’t solve the issue….
Cheers,
Jeff.
> On 22 Nov 2018, at 18:09, Jeff Young wrote:
>
> “Just saving in .dcm file” was how I meant it to work, but it is indeed
> buggy. Fixes on the way….
>
>> On 21 Nov 2018, at 18:46, Wayne Stambaugh wrote:
>>
“Just saving in .dcm file” was how I meant it to work, but it is indeed buggy.
Fixes on the way….
> On 21 Nov 2018, at 18:46, Wayne Stambaugh wrote:
>
> On 11/21/2018 1:17 PM, Rene Pöschl wrote:
>> On 21/11/2018 18:38, Jeff Young wrote:
Version 5.0.x (and version 4.0.x) gave us the option
On 11/21/2018 1:17 PM, Rene Pöschl wrote:
> On 21/11/2018 18:38, Jeff Young wrote:
>>> Version 5.0.x (and version 4.0.x) gave us the option to store the
>>> datasheets for both
>>> aliases and main symbols in the dcm file.
>> Right; that hasn’t changed. What’s changed (or should have changed)
>> i
On 21/11/2018 18:38, Jeff Young wrote:
Version 5.0.x (and version 4.0.x) gave us the option to store the datasheets
for both
aliases and main symbols in the dcm file.
Right; that hasn’t changed. What’s changed (or should have changed) is that
the above is the *only* option.
So is it not OK f
> Version 5.0.x (and version 4.0.x) gave us the option to store the datasheets
> for both
> aliases and main symbols in the dcm file.
Right; that hasn’t changed. What’s changed (or should have changed) is that
the above is the *only* option.
So is it not OK for that to be the only option, or i
On 11/21/18 11:41 AM, Jeff Young wrote:
@Wayne,
This is a limitation of the current symbol file format but the root datasheet
field
should be empty and the datasheet url should be stored in the document file
along with the description and keywords. This way it's consistent with all of
the
al
On 21/11/2018 17:41, Jeff Young wrote:
@Wayne,
This is a limitation of the current symbol file format but the root datasheet
field
should be empty and the datasheet url should be stored in the document file
along with the description and keywords. This way it's consistent with all of
the
ali
@Wayne,
> This is a limitation of the current symbol file format but the root datasheet
> field
> should be empty and the datasheet url should be stored in the document file
> along with the description and keywords. This way it's consistent with all
> of the
> alias information and doesn't
Hey Jeff,
This is a limitation of the current symbol file format but the root
datasheet field should be empty and the datasheet url should be stored
in the document file along with the description and keywords. This way
it's consistent with all of the alias information and doesn't violate
th
Hmm. The new scheme is far more regular, allows for a much simpler (read:
“less fragile”) implementation, and mimics what we’ll have with the new file
format in 6.0.
Can one of you say more about the issues it’s causing? The same data is being
stored, so I don’t understand how it could crea
It appears that this has indeed changed which has bitten me on my last
two symbol library pull requests. Had to manually edit the library and
document files so the root symbol datasheet was correct. We need to
change it back to the previous behavior.
On 11/20/2018 6:12 PM, Rene Pöschl wrote:
> I
Is it possible that the datasheet field has been moved to the lib file
in the current nightly builds? That would break our testscripts and
create unnecessary noise on github. I thought the solution (for v5) has
been that the field of the lib file is filled with the one from the dcm
file if it i
12 matches
Mail list logo