pcbnew library

Bug #703237 reported by biglacko
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KiCad
Fix Released
Undecided
Unassigned

Bug Description

Last svn in mandriva 2010.2 not read all library in pcbnew.
Not place all component on board.

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

It is only possible for us here on this mailing list to fix what is at the tip of *our* repo. By tip, I mean "very very latest" version within the repo.

Each distribution and/or platform has one or more "maintainer" individuals/people, who have volunteered or get paid to maintain the Kicad package for any respective target environment. Your posting is not clear as to where the binary came from: maintainer or from our repo.

If it does not pertain to the tip (very very latest) of our repo, it is not our responsibility, and you will have better results consulting with the maintainer of the package for your distro.

We ignore things here that do not pertain to the tip of our repo, and this mailing list or bug reporting system was setup to support the tip of our repo. Package maintainers can come back and reporting meaninful bugs, and so can individuals the build from code on the tip of our repo.

Please report the bug with the Mandriva package maintainer, if that is where the binary came from. Otherwise clarify where it came from at what BAZAAR version it is.

Thanks.

Changed in kicad:
status: New → Invalid
Changed in kicad:
status: Invalid → Incomplete
Revision history for this message
biglacko (biglacko) wrote :

Sorry, last BZR bazaar
Now on revision 2732.

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote : Re: [Bug 703237] Re: pcbnew library

I am not having problems with the BZR version 2733 (at least that I know of).

Do you have a simple board file that you can provide that exhibits the
problem? We can load it with both the newest and an older version. Or
better yet, can you checkout an older version and find the exact version at
which it got broken. If it is broken on all versions, then maybe it is
something you are doing wrong with your configuration.

Revision history for this message
jean-pierre charras (jp-charras) wrote :

Le 15/01/2011 17:38, Dick Hollenbeck a écrit :
> I am not having problems with the BZR version 2733 (at least that I know
> of).
>
> Do you have a simple board file that you can provide that exhibits the
> problem? We can load it with both the newest and an older version. Or
> better yet, can you checkout an older version and find the exact version at
> which it got broken. If it is broken on all versions, then maybe it is
> something you are doing wrong with your configuration.
>

Seems due to new FILTER_READER::ReadLine() that does not have exactly the same behavior than GetLine()
(GetLine() strips end of lines chars, and currently FILTER_READER::ReadLine() does not).
I fixed this now (obvious change), and I will commit this fix and some others fixes soon.

--
Jean-Pierre CHARRAS

Changed in kicad:
status: Incomplete → Fix Committed
Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

On 01/15/2011 11:53 AM, jean-pierre charras wrote:
> Le 15/01/2011 17:38, Dick Hollenbeck a écrit :
>> I am not having problems with the BZR version 2733 (at least that I know
>> of).
>>
>> Do you have a simple board file that you can provide that exhibits the
>> problem? We can load it with both the newest and an older version. Or
>> better yet, can you checkout an older version and find the exact version at
>> which it got broken. If it is broken on all versions, then maybe it is
>> something you are doing wrong with your configuration.
>>
> Seems due to new FILTER_READER::ReadLine() that does not have exactly the same behavior than GetLine()
> (GetLine() strips end of lines chars, and currently FILTER_READER::ReadLine() does not).
> I fixed this now (obvious change), and I will commit this fix and some others fixes soon.

That change breaks the API, which is that ReadLine() returns the number of
bytes in the line.

So I would like to measure the amount of work necessary for the caller of
ReadLine() to get fixed.

I reverted the change so someone can tell me where the caller is that is broken.

Dick

Revision history for this message
Marco Mattila (marcom99) wrote :

On Sun, Jan 16, 2011 at 12:52 AM, Dick Hollenbeck
<email address hidden> wrote:

> That change breaks the API, which is that ReadLine() returns the number of
> bytes in the line.
>
> So I would like to measure the amount of work necessary for the caller of
> ReadLine() to get fixed.
>
> I reverted the change so someone can tell me where the caller is that is
> broken.
>
> Dick

The problem seems to be that there's a string with the newline
character passed to CONV_TO_UTF8 in loadcmp.cpp. There's a StrPurge
missing between lines 316 and 317.

marco

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

On 01/15/2011 05:07 PM, Marco Mattila wrote:
> On Sun, Jan 16, 2011 at 12:52 AM, Dick Hollenbeck
> <email address hidden> wrote:
>
>> That change breaks the API, which is that ReadLine() returns the number of
>> bytes in the line.
>>
>> So I would like to measure the amount of work necessary for the caller of
>> ReadLine() to get fixed.
>>
>> I reverted the change so someone can tell me where the caller is that is
>> broken.
>>
>> Dick
> The problem seems to be that there's a string with the newline
> character passed to CONV_TO_UTF8 in loadcmp.cpp. There's a StrPurge
> missing between lines 316 and 317.
>
> marco

Marco,

Thank you for using the mailing list to help solve a problem. You are a
team player and I appreciate that.

The mailing list is here so we can discuss problems and work out solutions.

Do you want to fix it or should I? Do you think this is the last of the
issues?

BTW, nice catch.

Dick

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

On 01/15/2011 05:50 PM, Dick Hollenbeck wrote:
> On 01/15/2011 05:07 PM, Marco Mattila wrote:
>> On Sun, Jan 16, 2011 at 12:52 AM, Dick Hollenbeck
>> <email address hidden> wrote:
>>
>>> That change breaks the API, which is that ReadLine() returns the number of
>>> bytes in the line.
>>>
>>> So I would like to measure the amount of work necessary for the caller of
>>> ReadLine() to get fixed.
>>>
>>> I reverted the change so someone can tell me where the caller is that is
>>> broken.
>>>
>>> Dick
>> The problem seems to be that there's a string with the newline
>> character passed to CONV_TO_UTF8 in loadcmp.cpp. There's a StrPurge
>> missing between lines 316 and 317.
>>
>> marco

StrPurge() might need some enhancement WRT \r & \n

I don't see that it will clobber those as it should.

Dick

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

On 01/15/2011 06:00 PM, Dick Hollenbeck wrote:
> On 01/15/2011 05:50 PM, Dick Hollenbeck wrote:
>> On 01/15/2011 05:07 PM, Marco Mattila wrote:
>>> On Sun, Jan 16, 2011 at 12:52 AM, Dick Hollenbeck
>>> <email address hidden> wrote:
>>>
>>>> That change breaks the API, which is that ReadLine() returns the number of
>>>> bytes in the line.
>>>>
>>>> So I would like to measure the amount of work necessary for the caller of
>>>> ReadLine() to get fixed.
>>>>
>>>> I reverted the change so someone can tell me where the caller is that is
>>>> broken.
>>>>
>>>> Dick
>>> The problem seems to be that there's a string with the newline
>>> character passed to CONV_TO_UTF8 in loadcmp.cpp. There's a StrPurge
>>> missing between lines 316 and 317.
>>>
>>> marco
> StrPurge() might need some enhancement WRT \r & \n
>
> I don't see that it will clobber those as it should.

tabs also. I think they call this whitespace in the first semester C classes.

Dick

Revision history for this message
Marco Mattila (marcom99) wrote :

On Sun, Jan 16, 2011 at 2:01 AM, Dick Hollenbeck
<email address hidden> wrote:
>> StrPurge() might need some enhancement WRT \r & \n
>>
>> I don't see that it will clobber those as it should.
>
> tabs also.  I think they call this whitespace in the first semester C
> classes.

It attempts to ignore anything "smaller than" space. That does include
\n and \r doesn't it?

Anyways, i can fix the bug. There's another issue in librairi.cpp (an
extra fclose) I can fix at the same time.

This I should have noticed earlier already. However, I was
concentrating too much on the board file loading properly. The rest of
the file reading code *should* be fine with strings having newlines in
them. I can't promise that there are no other bugs, though.

marco

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

On 01/15/2011 06:21 PM, Marco Mattila wrote:
> On Sun, Jan 16, 2011 at 2:01 AM, Dick Hollenbeck
> <email address hidden> wrote:
>>> StrPurge() might need some enhancement WRT \r & \n
>>>
>>> I don't see that it will clobber those as it should.
>> tabs also. I think they call this whitespace in the first semester C
>> classes.
> It attempts to ignore anything "smaller than" space. That does include
> \n and \r doesn't it?

Sure, and all the 8 bit characters on machines that treat char as signed,
will also be considered less than ' '.
They will promote everything with bit 7 on to negative ints, including
actual ALL non-ASCII true UTF8 characters.

StrPurge() is broken for code moving forward, because:

*) on a machine where char is signed (machine choice), if bit 7 is on then
that char is negative and this function will not work.

I'll take a crack at fixing this function, and commit the change two
changes you mentioned. I think it best that we have the fixed code in
place by the time Jean-Pierre gets out of bed, since the need for a fix
seems to be urgent.

Dick

Revision history for this message
Dick Hollenbeck (dickelbeck) wrote :

biglacko,

Can you please confirm that the current code fixes the problem?

If not, please post a small board file that exhibits the problem and I will
fix it right away.

This bug is currently marked as FIX_COMMITTED, but since I never duplicated
the problem, I want to be sure the status of the bug report is accurate.

Thanks,

Dick

Revision history for this message
biglacko (biglacko) wrote :

Dick,
Problem fixed.
Thanks

Jon Neal (reportingsjr)
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.