Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Badr Hack]

Hi Wayne, 

We've just created a merge request in gitlab regarding this plugin
(!525). 

SCH_REMOTE_PLUGIN to retrieve symbol libraries remotely HTTP/HTTPS [1] 

We created a separate plugin similar to the existing ones. 

Perhaps we will need to rename it differently since github is not
relevant (it was analogically coded to match with pcbnew at the
begining). 

Regards, 

Alex 

Le 2020-05-20 14:23, Wayne Stambaugh a écrit :

> Creating a merge request on GitLab is now the only accepted way to
> contribute to KiCad.  Please create a merge request on GitLab so we can
> evaluate your change.
> 
> Cheers,
> 
> Wayne
> 
> On 5/20/20 6:51 AM, Nick Østergaard wrote: Maybe submit it as a MergeRequest 
> on gitlab.
> 
> ons. 20. maj 2020 12.16 skrev Badr Hack  >:
> 
> Hi Wayne,
> 
> Is there any update regarding this patch?
> 
> If there is any thing else to adjust please let me know.
> 
> For information, the plugin is working without any bug since 2018 in
> my for :)
> 
> Regards,
> 
> Badr
> 
> Le 2018-10-30 11:07, Badr Hack a écrit :
> 
> Hi Wayne,
> 
> Did you have a chance to give a look at this patch?
> From our side we are using it almost a year now, it works fine.
> 
> Else, I don't know if an equivalent function is now under going in
> the version 6?
> If so, I will be glad to help in testing.
> 
> Regards,
> 
> Badr
> 
> Le 2017-12-24 15:31, Wayne Stambaugh a écrit :
> 
> Badr,
> 
> Thank you for your patch but we are currently in feature
> freeze for the
> stable 5 release.  This patch will have to wait until the stable 5
> version is release and the version 6 development is opened. 
> I'm not
> sure exactly when that will happen but I will review your
> patch then.
> 
> Cheers,
> 
> Wayne
> 
> On 12/24/2017 05:56 AM, Badr Hack wrote:
> 
> Hi,
> Here is a patch to add the remote library management as a
> plugin.
> I added the possibility to specify multiple urls  in a
> single file, it
> was useful for our case.
> We tested this approach several weeks, it seems fine in
> term of
> performance.
> It doesn't support remote zip files as for pcbnew. I can
> manage to
> implement it in a second time.
> If this patch is ok I will write a detailed documentation
> on how to use it.
> Regards,
> Badr
> 
> Le 2017-08-14 15:21, Wayne Stambaugh a écrit :
> 
> You could modify the SCH_LEGACY_PLUGIN_CACHE code to
> handle urls instead
> of file names.  That way you could hand remote and
> local files in the
> same plugin.  wxWidgets has classes to handle urls
> (wxUrl) and input
> streams (wxInputStream) which can be use as the
> LINE_READER
> (INPUTSTREAM_LINE_READER takes a pointer to a
> wxInputStream object).
> The primary drawback to this is performance.  Past
> testing has shown
> that wxInputStream has a lot more overhead and is
> significantly slower
> than either our FILE_LINE_READER and std::istream so
> that is why we
> haven't used it anywhere.  It is also why I
> recommended writing a new
> plugin.  I'm guessing with remote I/O, the
> wxInputStream performance hit
> will be far less noticeable than the remote I/O time.
> 
> Wayne
> 
> On 8/14/2017 3:29 AM, Badr Hack wrote:
> 
> I see,
> I thought it would be better to upgrade
> SCH_LEGACY_PLUGIN_CACHE to
> handle remote libraries seemlessly rather than
> creating a new plugin.
> I will check how to add a new plugin for remote
> libs without adding
> additional actions for the user.
> 
> Badr
> 
> Le 2017-08-14 02:44, Wayne Stambaugh a écrit :
> 
> I think you misunderstood what I was
> implying.  You should not be
> looking for a different symbol library
> header.  This is a change that I
> would reject since you are effectively
> changing the library file
> format.
> What I suggested was that you create new
> plugin that reads from a
> remote url similar to the github plugin used
> for footprint libraries.
> 
> I also do not like the idea of a separate
> LoadRemote() method being
> added to the SCH_PLUGIN object.  There is no
> reason to add it.  All of
> the symbol library methods take a wxString
> which could be a url instead
> of a file name.  It is not limited to files
> and up to the plugin
> type to
> handle it correctly.  My preference is that
> you create a new plugin for
> remote files similar in concept to the github
> plugin.  That is the
> whole
> point of the current plugin interface.  Take a
> look at the board
> plugins
> to see the preferred method of creating plugins.
> 
> I never really intended for the legacy symbol
> file format to have
> multiple plugins like the kicad board and
> footprint library file
> formats
> so I didn't create separate parser and
> formatter objects like I did
> with
> the board file formats.  Nothing is preventing
> that from happening with
> the current schematic and symbol library file
> formats.  I would not
> have
> any objection to splitting the parser out of the
> SCH_LEGACY_PLUGIN_CACHE
> object.  I am planning on make the parsers and
> formatters for the new
> 

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Wayne Stambaugh]

Creating a merge request on GitLab is now the only accepted way to
contribute to KiCad.  Please create a merge request on GitLab so we can
evaluate your change.

Cheers,

Wayne

On 5/20/20 6:51 AM, Nick Østergaard wrote:
> Maybe submit it as a MergeRequest on gitlab.
> 
> ons. 20. maj 2020 12.16 skrev Badr Hack  >:
> 
> Hi Wayne,
> 
> Is there any update regarding this patch?
> 
> If there is any thing else to adjust please let me know.
> 
> For information, the plugin is working without any bug since 2018 in
> my for :)
> 
> Regards,
> 
> Badr
> 
> Le 2018-10-30 11:07, Badr Hack a écrit :
> 
>> Hi Wayne,
>>
>> Did you have a chance to give a look at this patch?
>> From our side we are using it almost a year now, it works fine.
>>
>> Else, I don't know if an equivalent function is now under going in
>> the version 6?
>> If so, I will be glad to help in testing.
>>
>> Regards,
>>
>> Badr
>>
>> Le 2017-12-24 15:31, Wayne Stambaugh a écrit :
>>
>> Badr,
>>
>> Thank you for your patch but we are currently in feature
>> freeze for the
>> stable 5 release.  This patch will have to wait until the stable 5
>> version is release and the version 6 development is opened. 
>> I'm not
>> sure exactly when that will happen but I will review your
>> patch then.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 12/24/2017 05:56 AM, Badr Hack wrote:
>>
>> Hi,
>> Here is a patch to add the remote library management as a
>> plugin.
>> I added the possibility to specify multiple urls  in a
>> single file, it
>> was useful for our case.
>> We tested this approach several weeks, it seems fine in
>> term of
>> performance.
>> It doesn't support remote zip files as for pcbnew. I can
>> manage to
>> implement it in a second time.
>> If this patch is ok I will write a detailed documentation
>> on how to use it.
>> Regards,
>> Badr
>>
>>
>> Le 2017-08-14 15:21, Wayne Stambaugh a écrit :
>>
>> You could modify the SCH_LEGACY_PLUGIN_CACHE code to
>> handle urls instead
>> of file names.  That way you could hand remote and
>> local files in the
>> same plugin.  wxWidgets has classes to handle urls
>> (wxUrl) and input
>> streams (wxInputStream) which can be use as the
>> LINE_READER
>> (INPUTSTREAM_LINE_READER takes a pointer to a
>> wxInputStream object).
>> The primary drawback to this is performance.  Past
>> testing has shown
>> that wxInputStream has a lot more overhead and is
>> significantly slower
>> than either our FILE_LINE_READER and std::istream so
>> that is why we
>> haven't used it anywhere.  It is also why I
>> recommended writing a new
>> plugin.  I'm guessing with remote I/O, the
>> wxInputStream performance hit
>> will be far less noticeable than the remote I/O time.
>>
>> Wayne
>>
>> On 8/14/2017 3:29 AM, Badr Hack wrote:
>>
>> I see,
>> I thought it would be better to upgrade
>> SCH_LEGACY_PLUGIN_CACHE to
>> handle remote libraries seemlessly rather than
>> creating a new plugin.
>> I will check how to add a new plugin for remote
>> libs without adding
>> additional actions for the user.
>>
>> Badr
>>
>> Le 2017-08-14 02:44, Wayne Stambaugh a écrit :
>>
>> I think you misunderstood what I was
>> implying.  You should not be
>> looking for a different symbol library
>> header.  This is a change that I
>> would reject since you are effectively
>> changing the library file
>> format.
>>  What I suggested was that you create new
>> plugin that reads from a
>> remote url similar to the github plugin used
>> for footprint libraries.
>>
>> I also do not like the idea of a separate
>> LoadRemote() method being
>> added to the SCH_PLUGIN object.  There is no
>> reason to add it.  All of
>> the symbol library methods take a 

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Nick Østergaard]

Maybe submit it as a MergeRequest on gitlab.

ons. 20. maj 2020 12.16 skrev Badr Hack :

> Hi Wayne,
>
> Is there any update regarding this patch?
>
> If there is any thing else to adjust please let me know.
>
> For information, the plugin is working without any bug since 2018 in my
> for :)
>
> Regards,
>
> Badr
>
> Le 2018-10-30 11:07, Badr Hack a écrit :
>
> Hi Wayne,
>
> Did you have a chance to give a look at this patch?
> From our side we are using it almost a year now, it works fine.
>
> Else, I don't know if an equivalent function is now under going in the
> version 6?
> If so, I will be glad to help in testing.
>
> Regards,
>
> Badr
>
> Le 2017-12-24 15:31, Wayne Stambaugh a écrit :
>
> Badr,
>
> Thank you for your patch but we are currently in feature freeze for the
> stable 5 release.  This patch will have to wait until the stable 5
> version is release and the version 6 development is opened.  I'm not
> sure exactly when that will happen but I will review your patch then.
>
> Cheers,
>
> Wayne
>
> On 12/24/2017 05:56 AM, Badr Hack wrote:
>
> Hi,
> Here is a patch to add the remote library management as a plugin.
> I added the possibility to specify multiple urls  in a single file, it
> was useful for our case.
> We tested this approach several weeks, it seems fine in term of
> performance.
> It doesn't support remote zip files as for pcbnew. I can manage to
> implement it in a second time.
> If this patch is ok I will write a detailed documentation on how to use it.
> Regards,
> Badr
>
>
> Le 2017-08-14 15:21, Wayne Stambaugh a écrit :
>
> You could modify the SCH_LEGACY_PLUGIN_CACHE code to handle urls instead
> of file names.  That way you could hand remote and local files in the
> same plugin.  wxWidgets has classes to handle urls (wxUrl) and input
> streams (wxInputStream) which can be use as the LINE_READER
> (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object).
> The primary drawback to this is performance.  Past testing has shown
> that wxInputStream has a lot more overhead and is significantly slower
> than either our FILE_LINE_READER and std::istream so that is why we
> haven't used it anywhere.  It is also why I recommended writing a new
> plugin.  I'm guessing with remote I/O, the wxInputStream performance hit
> will be far less noticeable than the remote I/O time.
>
> Wayne
>
> On 8/14/2017 3:29 AM, Badr Hack wrote:
>
> I see,
> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to
> handle remote libraries seemlessly rather than creating a new plugin.
> I will check how to add a new plugin for remote libs without adding
> additional actions for the user.
>
> Badr
>
> Le 2017-08-14 02:44, Wayne Stambaugh a écrit :
>
> I think you misunderstood what I was implying.  You should not be
> looking for a different symbol library header.  This is a change that I
> would reject since you are effectively changing the library file
> format.
>  What I suggested was that you create new plugin that reads from a
> remote url similar to the github plugin used for footprint libraries.
>
> I also do not like the idea of a separate LoadRemote() method being
> added to the SCH_PLUGIN object.  There is no reason to add it.  All of
> the symbol library methods take a wxString which could be a url instead
> of a file name.  It is not limited to files and up to the plugin
> type to
> handle it correctly.  My preference is that you create a new plugin for
> remote files similar in concept to the github plugin.  That is the
> whole
> point of the current plugin interface.  Take a look at the board
> plugins
> to see the preferred method of creating plugins.
>
> I never really intended for the legacy symbol file format to have
> multiple plugins like the kicad board and footprint library file
> formats
> so I didn't create separate parser and formatter objects like I did
> with
> the board file formats.  Nothing is preventing that from happening with
> the current schematic and symbol library file formats.  I would not
> have
> any objection to splitting the parser out of the
> SCH_LEGACY_PLUGIN_CACHE
> object.  I am planning on make the parsers and formatters for the new
> schematic and symbol library file format code separate so it can be
> used
> by any plugin.
>
> Cheers,
>
> Wayne
>
> On 8/13/2017 3:26 PM, Badr Hack wrote:
>
> Hi,
>
> Here in the attachment the patch that add the remote lib retrieval.
>
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit :
>
> Hi,
>
> Those couple of days I was checking how to update EESCHEMA to add
> remote libraries retrieval function.
>
> Since am familiar with legacy format, I updated the plugin:
> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>
> The idea was to create a new type of library
> EESchema-REMOTELIBRARY (I
> put an example in the attachment)
> The content of this library is the following:
> EESchema-REMOTELIBRARY Version 1.0
> URL https://www.example.com/mylib1.lib
> URL https://www.example.com/mylib2.lib
> ...
>

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Badr Hack]

Hi Wayne, 

Is there any update regarding this patch? 

If there is any thing else to adjust please let me know. 

For information, the plugin is working without any bug since 2018 in my
for :) 

Regards, 

Badr 

Le 2018-10-30 11:07, Badr Hack a écrit :

> Hi Wayne, 
> 
> Did you have a chance to give a look at this patch?
> From our side we are using it almost a year now, it works fine. 
> 
> Else, I don't know if an equivalent function is now under going in the 
> version 6?
> If so, I will be glad to help in testing. 
> 
> Regards, 
> 
> Badr 
> 
> Le 2017-12-24 15:31, Wayne Stambaugh a écrit : 
> Badr,
> 
> Thank you for your patch but we are currently in feature freeze for the
> stable 5 release.  This patch will have to wait until the stable 5
> version is release and the version 6 development is opened.  I'm not
> sure exactly when that will happen but I will review your patch then.
> 
> Cheers,
> 
> Wayne
> 
> On 12/24/2017 05:56 AM, Badr Hack wrote: Hi,
> Here is a patch to add the remote library management as a plugin.
> I added the possibility to specify multiple urls  in a single file, it
> was useful for our case.
> We tested this approach several weeks, it seems fine in term of
> performance.
> It doesn't support remote zip files as for pcbnew. I can manage to
> implement it in a second time.
> If this patch is ok I will write a detailed documentation on how to use it.
> Regards,
> Badr
> 
> Le 2017-08-14 15:21, Wayne Stambaugh a écrit : You could modify the 
> SCH_LEGACY_PLUGIN_CACHE code to handle urls instead
> of file names.  That way you could hand remote and local files in the
> same plugin.  wxWidgets has classes to handle urls (wxUrl) and input
> streams (wxInputStream) which can be use as the LINE_READER
> (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object).
> The primary drawback to this is performance.  Past testing has shown
> that wxInputStream has a lot more overhead and is significantly slower
> than either our FILE_LINE_READER and std::istream so that is why we
> haven't used it anywhere.  It is also why I recommended writing a new
> plugin.  I'm guessing with remote I/O, the wxInputStream performance hit
> will be far less noticeable than the remote I/O time.
> 
> Wayne
> 
> On 8/14/2017 3:29 AM, Badr Hack wrote: I see,
> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to
> handle remote libraries seemlessly rather than creating a new plugin.
> I will check how to add a new plugin for remote libs without adding
> additional actions for the user.
> 
> Badr
> 
> Le 2017-08-14 02:44, Wayne Stambaugh a écrit : I think you misunderstood what 
> I was implying.  You should not be
> looking for a different symbol library header.  This is a change that I
> would reject since you are effectively changing the library file
> format.
> What I suggested was that you create new plugin that reads from a
> remote url similar to the github plugin used for footprint libraries.
> 
> I also do not like the idea of a separate LoadRemote() method being
> added to the SCH_PLUGIN object.  There is no reason to add it.  All of
> the symbol library methods take a wxString which could be a url instead
> of a file name.  It is not limited to files and up to the plugin
> type to
> handle it correctly.  My preference is that you create a new plugin for
> remote files similar in concept to the github plugin.  That is the
> whole
> point of the current plugin interface.  Take a look at the board
> plugins
> to see the preferred method of creating plugins.
> 
> I never really intended for the legacy symbol file format to have
> multiple plugins like the kicad board and footprint library file
> formats
> so I didn't create separate parser and formatter objects like I did
> with
> the board file formats.  Nothing is preventing that from happening with
> the current schematic and symbol library file formats.  I would not
> have
> any objection to splitting the parser out of the
> SCH_LEGACY_PLUGIN_CACHE
> object.  I am planning on make the parsers and formatters for the new
> schematic and symbol library file format code separate so it can be
> used
> by any plugin.
> 
> Cheers,
> 
> Wayne
> 
> On 8/13/2017 3:26 PM, Badr Hack wrote: Hi,
> 
> Here in the attachment the patch that add the remote lib retrieval.
> 
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit : Hi,
> 
> Those couple of days I was checking how to update EESCHEMA to add
> remote libraries retrieval function.
> 
> Since am familiar with legacy format, I updated the plugin:
> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
> 
> The idea was to create a new type of library
> EESchema-REMOTELIBRARY (I
> put an example in the attachment)
> The content of this library is the following:
> EESchema-REMOTELIBRARY Version 1.0
> URL https://www.example.com/mylib1.lib
> URL https://www.example.com/mylib2.lib
> ...
> 
> This lib file is saved localy and specify the path of each remote
> library you want to 

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Badr Hack]

Hi Wayne, 

Did you have a chance to give a look at this patch?
>From our side we are using it almost a year now, it works fine. 

Else, I don't know if an equivalent function is now under going in the
version 6?
If so, I will be glad to help in testing. 

Regards, 

Badr 

Le 2017-12-24 15:31, Wayne Stambaugh a écrit :

> Badr,
> 
> Thank you for your patch but we are currently in feature freeze for the
> stable 5 release.  This patch will have to wait until the stable 5
> version is release and the version 6 development is opened.  I'm not
> sure exactly when that will happen but I will review your patch then.
> 
> Cheers,
> 
> Wayne
> 
> On 12/24/2017 05:56 AM, Badr Hack wrote: Hi,
> Here is a patch to add the remote library management as a plugin.
> I added the possibility to specify multiple urls  in a single file, it
> was useful for our case.
> We tested this approach several weeks, it seems fine in term of
> performance.
> It doesn't support remote zip files as for pcbnew. I can manage to
> implement it in a second time.
> If this patch is ok I will write a detailed documentation on how to use it.
> Regards,
> Badr
> 
> Le 2017-08-14 15:21, Wayne Stambaugh a écrit : You could modify the 
> SCH_LEGACY_PLUGIN_CACHE code to handle urls instead
> of file names.  That way you could hand remote and local files in the
> same plugin.  wxWidgets has classes to handle urls (wxUrl) and input
> streams (wxInputStream) which can be use as the LINE_READER
> (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object).
> The primary drawback to this is performance.  Past testing has shown
> that wxInputStream has a lot more overhead and is significantly slower
> than either our FILE_LINE_READER and std::istream so that is why we
> haven't used it anywhere.  It is also why I recommended writing a new
> plugin.  I'm guessing with remote I/O, the wxInputStream performance hit
> will be far less noticeable than the remote I/O time.
> 
> Wayne
> 
> On 8/14/2017 3:29 AM, Badr Hack wrote: I see,
> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to
> handle remote libraries seemlessly rather than creating a new plugin.
> I will check how to add a new plugin for remote libs without adding
> additional actions for the user.
> 
> Badr
> 
> Le 2017-08-14 02:44, Wayne Stambaugh a écrit : I think you misunderstood what 
> I was implying.  You should not be
> looking for a different symbol library header.  This is a change that I
> would reject since you are effectively changing the library file
> format.
> What I suggested was that you create new plugin that reads from a
> remote url similar to the github plugin used for footprint libraries.
> 
> I also do not like the idea of a separate LoadRemote() method being
> added to the SCH_PLUGIN object.  There is no reason to add it.  All of
> the symbol library methods take a wxString which could be a url instead
> of a file name.  It is not limited to files and up to the plugin
> type to
> handle it correctly.  My preference is that you create a new plugin for
> remote files similar in concept to the github plugin.  That is the
> whole
> point of the current plugin interface.  Take a look at the board
> plugins
> to see the preferred method of creating plugins.
> 
> I never really intended for the legacy symbol file format to have
> multiple plugins like the kicad board and footprint library file
> formats
> so I didn't create separate parser and formatter objects like I did
> with
> the board file formats.  Nothing is preventing that from happening with
> the current schematic and symbol library file formats.  I would not
> have
> any objection to splitting the parser out of the
> SCH_LEGACY_PLUGIN_CACHE
> object.  I am planning on make the parsers and formatters for the new
> schematic and symbol library file format code separate so it can be
> used
> by any plugin.
> 
> Cheers,
> 
> Wayne
> 
> On 8/13/2017 3:26 PM, Badr Hack wrote: Hi,
> 
> Here in the attachment the patch that add the remote lib retrieval.
> 
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit : Hi,
> 
> Those couple of days I was checking how to update EESCHEMA to add
> remote libraries retrieval function.
> 
> Since am familiar with legacy format, I updated the plugin:
> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
> 
> The idea was to create a new type of library
> EESchema-REMOTELIBRARY (I
> put an example in the attachment)
> The content of this library is the following:
> EESchema-REMOTELIBRARY Version 1.0
> URL https://www.example.com/mylib1.lib
> URL https://www.example.com/mylib2.lib
> ...
> 
> This lib file is saved localy and specify the path of each remote
> library you want to retrieve.
> 
> The updated code seemlessly check the type of the library, if it is
> EESchema-LIBRARY it parse it like always, else if it is
> EESchema-REMOTELIBRARY it download each remote lib and parse it when
> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
> 
> The 

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Wayne Stambaugh]

Badr,

Thank you for your patch but we are currently in feature freeze for the
stable 5 release.  This patch will have to wait until the stable 5
version is release and the version 6 development is opened.  I'm not
sure exactly when that will happen but I will review your patch then.

Cheers,

Wayne

On 12/24/2017 05:56 AM, Badr Hack wrote:
> Hi,
> Here is a patch to add the remote library management as a plugin.
> I added the possibility to specify multiple urls  in a single file, it
> was useful for our case.
> We tested this approach several weeks, it seems fine in term of
> performance.
> It doesn't support remote zip files as for pcbnew. I can manage to
> implement it in a second time.
> If this patch is ok I will write a detailed documentation on how to use it.
> Regards,
> Badr
> 
> 
> Le 2017-08-14 15:21, Wayne Stambaugh a écrit :
>> You could modify the SCH_LEGACY_PLUGIN_CACHE code to handle urls instead
>> of file names.  That way you could hand remote and local files in the
>> same plugin.  wxWidgets has classes to handle urls (wxUrl) and input
>> streams (wxInputStream) which can be use as the LINE_READER
>> (INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object).
>> The primary drawback to this is performance.  Past testing has shown
>> that wxInputStream has a lot more overhead and is significantly slower
>> than either our FILE_LINE_READER and std::istream so that is why we
>> haven't used it anywhere.  It is also why I recommended writing a new
>> plugin.  I'm guessing with remote I/O, the wxInputStream performance hit
>> will be far less noticeable than the remote I/O time.
>>
>> Wayne
>>
>> On 8/14/2017 3:29 AM, Badr Hack wrote:
>>> I see,
>>> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to
>>> handle remote libraries seemlessly rather than creating a new plugin.
>>> I will check how to add a new plugin for remote libs without adding
>>> additional actions for the user.
>>>
>>> Badr
>>>
>>> Le 2017-08-14 02:44, Wayne Stambaugh a écrit :
 I think you misunderstood what I was implying.  You should not be
 looking for a different symbol library header.  This is a change that I
 would reject since you are effectively changing the library file
 format.
  What I suggested was that you create new plugin that reads from a
 remote url similar to the github plugin used for footprint libraries.

 I also do not like the idea of a separate LoadRemote() method being
 added to the SCH_PLUGIN object.  There is no reason to add it.  All of
 the symbol library methods take a wxString which could be a url instead
 of a file name.  It is not limited to files and up to the plugin
 type to
 handle it correctly.  My preference is that you create a new plugin for
 remote files similar in concept to the github plugin.  That is the
 whole
 point of the current plugin interface.  Take a look at the board
 plugins
 to see the preferred method of creating plugins.

 I never really intended for the legacy symbol file format to have
 multiple plugins like the kicad board and footprint library file
 formats
 so I didn't create separate parser and formatter objects like I did
 with
 the board file formats.  Nothing is preventing that from happening with
 the current schematic and symbol library file formats.  I would not
 have
 any objection to splitting the parser out of the
 SCH_LEGACY_PLUGIN_CACHE
 object.  I am planning on make the parsers and formatters for the new
 schematic and symbol library file format code separate so it can be
 used
 by any plugin.

 Cheers,

 Wayne

 On 8/13/2017 3:26 PM, Badr Hack wrote:
> Hi,
>
> Here in the attachment the patch that add the remote lib retrieval.
>
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit :
>> Hi,
>>
>> Those couple of days I was checking how to update EESCHEMA to add
>> remote libraries retrieval function.
>>
>> Since am familiar with legacy format, I updated the plugin:
>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>
>> The idea was to create a new type of library
>> EESchema-REMOTELIBRARY (I
>> put an example in the attachment)
>> The content of this library is the following:
>> EESchema-REMOTELIBRARY Version 1.0
>> URL https://www.example.com/mylib1.lib
>> URL https://www.example.com/mylib2.lib
>> ...
>>
>> This lib file is saved localy and specify the path of each remote
>> library you want to retrieve.
>>
>> The updated code seemlessly check the type of the library, if it is
>> EESchema-LIBRARY it parse it like always, else if it is
>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>
>> The impacted files are:  sch_legacy_plugin.cpp and

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Wayne Stambaugh]

You could modify the SCH_LEGACY_PLUGIN_CACHE code to handle urls instead
of file names.  That way you could hand remote and local files in the
same plugin.  wxWidgets has classes to handle urls (wxUrl) and input
streams (wxInputStream) which can be use as the LINE_READER
(INPUTSTREAM_LINE_READER takes a pointer to a wxInputStream object).
The primary drawback to this is performance.  Past testing has shown
that wxInputStream has a lot more overhead and is significantly slower
than either our FILE_LINE_READER and std::istream so that is why we
haven't used it anywhere.  It is also why I recommended writing a new
plugin.  I'm guessing with remote I/O, the wxInputStream performance hit
will be far less noticeable than the remote I/O time.

Wayne

On 8/14/2017 3:29 AM, Badr Hack wrote:
> I see,
> I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to
> handle remote libraries seemlessly rather than creating a new plugin.
> I will check how to add a new plugin for remote libs without adding
> additional actions for the user.
> 
> Badr
> 
> Le 2017-08-14 02:44, Wayne Stambaugh a écrit :
>> I think you misunderstood what I was implying.  You should not be
>> looking for a different symbol library header.  This is a change that I
>> would reject since you are effectively changing the library file format.
>>  What I suggested was that you create new plugin that reads from a
>> remote url similar to the github plugin used for footprint libraries.
>>
>> I also do not like the idea of a separate LoadRemote() method being
>> added to the SCH_PLUGIN object.  There is no reason to add it.  All of
>> the symbol library methods take a wxString which could be a url instead
>> of a file name.  It is not limited to files and up to the plugin type to
>> handle it correctly.  My preference is that you create a new plugin for
>> remote files similar in concept to the github plugin.  That is the whole
>> point of the current plugin interface.  Take a look at the board plugins
>> to see the preferred method of creating plugins.
>>
>> I never really intended for the legacy symbol file format to have
>> multiple plugins like the kicad board and footprint library file formats
>> so I didn't create separate parser and formatter objects like I did with
>> the board file formats.  Nothing is preventing that from happening with
>> the current schematic and symbol library file formats.  I would not have
>> any objection to splitting the parser out of the SCH_LEGACY_PLUGIN_CACHE
>> object.  I am planning on make the parsers and formatters for the new
>> schematic and symbol library file format code separate so it can be used
>> by any plugin.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 8/13/2017 3:26 PM, Badr Hack wrote:
>>> Hi,
>>>
>>> Here in the attachment the patch that add the remote lib retrieval.
>>>
>>> Badr
>>> Le 2017-08-13 17:29, Badr Hack a écrit :
 Hi,

 Those couple of days I was checking how to update EESCHEMA to add
 remote libraries retrieval function.

 Since am familiar with legacy format, I updated the plugin:
 SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.

 The idea was to create a new type of library EESchema-REMOTELIBRARY (I
 put an example in the attachment)
 The content of this library is the following:
 EESchema-REMOTELIBRARY Version 1.0
 URL https://www.example.com/mylib1.lib
 URL https://www.example.com/mylib2.lib
 ...

 This lib file is saved localy and specify the path of each remote
 library you want to retrieve.

 The updated code seemlessly check the type of the library, if it is
 EESchema-LIBRARY it parse it like always, else if it is
 EESchema-REMOTELIBRARY it download each remote lib and parse it when
 it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).

 The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
 -> I implemented the algo and made some tweeks to use LINE_READER
 instead of FILE_LINE_READER as argument to manage to use
 STRING_LINE_READER

 I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
 CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
 https requests. This modification is not required, but was useflul for
 our case where our server is behind ssl without certificate on the
 domaine, just ip addresses.

 I made a prototype in the attachment, it is woring.

 I don't know if this modification is inline with the arachitecture of
 kicad?

 Badr
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Badr Hack]

I see,
I thought it would be better to upgrade SCH_LEGACY_PLUGIN_CACHE to 
handle remote libraries seemlessly rather than creating a new plugin.
I will check how to add a new plugin for remote libs without adding 
additional actions for the user.


Badr

Le 2017-08-14 02:44, Wayne Stambaugh a écrit :

I think you misunderstood what I was implying.  You should not be
looking for a different symbol library header.  This is a change that I
would reject since you are effectively changing the library file 
format.

 What I suggested was that you create new plugin that reads from a
remote url similar to the github plugin used for footprint libraries.

I also do not like the idea of a separate LoadRemote() method being
added to the SCH_PLUGIN object.  There is no reason to add it.  All of
the symbol library methods take a wxString which could be a url instead
of a file name.  It is not limited to files and up to the plugin type 
to

handle it correctly.  My preference is that you create a new plugin for
remote files similar in concept to the github plugin.  That is the 
whole
point of the current plugin interface.  Take a look at the board 
plugins

to see the preferred method of creating plugins.

I never really intended for the legacy symbol file format to have
multiple plugins like the kicad board and footprint library file 
formats
so I didn't create separate parser and formatter objects like I did 
with

the board file formats.  Nothing is preventing that from happening with
the current schematic and symbol library file formats.  I would not 
have
any objection to splitting the parser out of the 
SCH_LEGACY_PLUGIN_CACHE

object.  I am planning on make the parsers and formatters for the new
schematic and symbol library file format code separate so it can be 
used

by any plugin.

Cheers,

Wayne

On 8/13/2017 3:26 PM, Badr Hack wrote:

Hi,

Here in the attachment the patch that add the remote lib retrieval.

Badr
Le 2017-08-13 17:29, Badr Hack a écrit :

Hi,

Those couple of days I was checking how to update EESCHEMA to add
remote libraries retrieval function.

Since am familiar with legacy format, I updated the plugin:
SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.

The idea was to create a new type of library EESchema-REMOTELIBRARY 
(I

put an example in the attachment)
The content of this library is the following:
EESchema-REMOTELIBRARY Version 1.0
URL https://www.example.com/mylib1.lib
URL https://www.example.com/mylib2.lib
...

This lib file is saved localy and specify the path of each remote
library you want to retrieve.

The updated code seemlessly check the type of the library, if it is
EESchema-LIBRARY it parse it like always, else if it is
EESchema-REMOTELIBRARY it download each remote lib and parse it when
it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).

The impacted files are:  sch_legacy_plugin.cpp and 
sch_legacy_plugin.h

-> I implemented the algo and made some tweeks to use LINE_READER
instead of FILE_LINE_READER as argument to manage to use
STRING_LINE_READER

I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
https requests. This modification is not required, but was useflul 
for

our case where our server is behind ssl without certificate on the
domaine, just ip addresses.

I made a prototype in the attachment, it is woring.

I don't know if this modification is inline with the arachitecture of
kicad?

Badr



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Wayne Stambaugh]

I think you misunderstood what I was implying.  You should not be
looking for a different symbol library header.  This is a change that I
would reject since you are effectively changing the library file format.
 What I suggested was that you create new plugin that reads from a
remote url similar to the github plugin used for footprint libraries.

I also do not like the idea of a separate LoadRemote() method being
added to the SCH_PLUGIN object.  There is no reason to add it.  All of
the symbol library methods take a wxString which could be a url instead
of a file name.  It is not limited to files and up to the plugin type to
handle it correctly.  My preference is that you create a new plugin for
remote files similar in concept to the github plugin.  That is the whole
point of the current plugin interface.  Take a look at the board plugins
to see the preferred method of creating plugins.

I never really intended for the legacy symbol file format to have
multiple plugins like the kicad board and footprint library file formats
so I didn't create separate parser and formatter objects like I did with
the board file formats.  Nothing is preventing that from happening with
the current schematic and symbol library file formats.  I would not have
any objection to splitting the parser out of the SCH_LEGACY_PLUGIN_CACHE
object.  I am planning on make the parsers and formatters for the new
schematic and symbol library file format code separate so it can be used
by any plugin.

Cheers,

Wayne

On 8/13/2017 3:26 PM, Badr Hack wrote:
> Hi,
> 
> Here in the attachment the patch that add the remote lib retrieval.
> 
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit :
>> Hi,
>>
>> Those couple of days I was checking how to update EESCHEMA to add
>> remote libraries retrieval function.
>>
>> Since am familiar with legacy format, I updated the plugin:
>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>
>> The idea was to create a new type of library EESchema-REMOTELIBRARY (I
>> put an example in the attachment)
>> The content of this library is the following:
>> EESchema-REMOTELIBRARY Version 1.0
>> URL https://www.example.com/mylib1.lib
>> URL https://www.example.com/mylib2.lib
>> ...
>>
>> This lib file is saved localy and specify the path of each remote
>> library you want to retrieve.
>>
>> The updated code seemlessly check the type of the library, if it is
>> EESchema-LIBRARY it parse it like always, else if it is
>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>
>> The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
>> -> I implemented the algo and made some tweeks to use LINE_READER
>> instead of FILE_LINE_READER as argument to manage to use
>> STRING_LINE_READER
>>
>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
>> https requests. This modification is not required, but was useflul for
>> our case where our server is behind ssl without certificate on the
>> domaine, just ip addresses.
>>
>> I made a prototype in the attachment, it is woring.
>>
>> I don't know if this modification is inline with the arachitecture of
>> kicad?
>>
>> Badr
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Simon Wells]

sorry i mean setting it to 0

On 14 August 2017 at 08:39, Simon Wells  wrote:
> setting CURLOPT_SSL_VERIFYHOST breaks newer ssl on macOS so likely
> better to not just disable that
>
> On 14 August 2017 at 07:26, Badr Hack  wrote:
>> Hi,
>>
>> Here in the attachment the patch that add the remote lib retrieval.
>>
>> Badr
>> Le 2017-08-13 17:29, Badr Hack a écrit :
>>>
>>> Hi,
>>>
>>> Those couple of days I was checking how to update EESCHEMA to add
>>> remote libraries retrieval function.
>>>
>>> Since am familiar with legacy format, I updated the plugin:
>>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>>
>>> The idea was to create a new type of library EESchema-REMOTELIBRARY (I
>>> put an example in the attachment)
>>> The content of this library is the following:
>>> EESchema-REMOTELIBRARY Version 1.0
>>> URL https://www.example.com/mylib1.lib
>>> URL https://www.example.com/mylib2.lib
>>> ...
>>>
>>> This lib file is saved localy and specify the path of each remote
>>> library you want to retrieve.
>>>
>>> The updated code seemlessly check the type of the library, if it is
>>> EESchema-LIBRARY it parse it like always, else if it is
>>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>>
>>> The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
>>> -> I implemented the algo and made some tweeks to use LINE_READER
>>> instead of FILE_LINE_READER as argument to manage to use
>>> STRING_LINE_READER
>>>
>>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
>>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
>>> https requests. This modification is not required, but was useflul for
>>> our case where our server is behind ssl without certificate on the
>>> domaine, just ip addresses.
>>>
>>> I made a prototype in the attachment, it is woring.
>>>
>>> I don't know if this modification is inline with the arachitecture of
>>> kicad?
>>>
>>> Badr
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Simon Wells]

setting CURLOPT_SSL_VERIFYHOST breaks newer ssl on macOS so likely
better to not just disable that

On 14 August 2017 at 07:26, Badr Hack  wrote:
> Hi,
>
> Here in the attachment the patch that add the remote lib retrieval.
>
> Badr
> Le 2017-08-13 17:29, Badr Hack a écrit :
>>
>> Hi,
>>
>> Those couple of days I was checking how to update EESCHEMA to add
>> remote libraries retrieval function.
>>
>> Since am familiar with legacy format, I updated the plugin:
>> SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.
>>
>> The idea was to create a new type of library EESchema-REMOTELIBRARY (I
>> put an example in the attachment)
>> The content of this library is the following:
>> EESchema-REMOTELIBRARY Version 1.0
>> URL https://www.example.com/mylib1.lib
>> URL https://www.example.com/mylib2.lib
>> ...
>>
>> This lib file is saved localy and specify the path of each remote
>> library you want to retrieve.
>>
>> The updated code seemlessly check the type of the library, if it is
>> EESchema-LIBRARY it parse it like always, else if it is
>> EESchema-REMOTELIBRARY it download each remote lib and parse it when
>> it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).
>>
>> The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
>> -> I implemented the algo and made some tweeks to use LINE_READER
>> instead of FILE_LINE_READER as argument to manage to use
>> STRING_LINE_READER
>>
>> I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
>> CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
>> https requests. This modification is not required, but was useflul for
>> our case where our server is behind ssl without certificate on the
>> domaine, just ip addresses.
>>
>> I made a prototype in the attachment, it is woring.
>>
>> I don't know if this modification is inline with the arachitecture of
>> kicad?
>>
>> Badr
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

[Badr Hack]

Hi,

Here in the attachment the patch that add the remote lib retrieval.

Badr
Le 2017-08-13 17:29, Badr Hack a écrit :

Hi,

Those couple of days I was checking how to update EESCHEMA to add
remote libraries retrieval function.

Since am familiar with legacy format, I updated the plugin:
SCH_LEGACY_PLUGIN_CACHE in charge of parsing the *.lib files.

The idea was to create a new type of library EESchema-REMOTELIBRARY (I
put an example in the attachment)
The content of this library is the following:
EESchema-REMOTELIBRARY Version 1.0
URL https://www.example.com/mylib1.lib
URL https://www.example.com/mylib2.lib
...

This lib file is saved localy and specify the path of each remote
library you want to retrieve.

The updated code seemlessly check the type of the library, if it is
EESchema-LIBRARY it parse it like always, else if it is
EESchema-REMOTELIBRARY it download each remote lib and parse it when
it is EESchema-LIBRARY (no recusivity with EESchema-REMOTELIBRARY).

The impacted files are:  sch_legacy_plugin.cpp and sch_legacy_plugin.h
-> I implemented the algo and made some tweeks to use LINE_READER
instead of FILE_LINE_READER as argument to manage to use
STRING_LINE_READER

I also modified KICAD_CURL_EASY::KICAD_CURL_EASY() to set the option
CURLOPT_SSL_VERIFYHOST to 0 to disable ssl certificate checking in
https requests. This modification is not required, but was useflul for
our case where our server is behind ssl without certificate on the
domaine, just ip addresses.

I made a prototype in the attachment, it is woring.

I don't know if this modification is inline with the arachitecture of 
kicad?


Badr
From 896cbc5f18bd8bf3d6a1258fc2b1824188e12b24 Mon Sep 17 00:00:00 2001
From: badr elhassak 
Date: Sun, 13 Aug 2017 21:13:43 +0200
Subject: [PATCH] Add remote lib retrieval to SCH_LEGACY_PLUGIN_CACHE

---
 common/kicad_curl/kicad_curl_easy.cpp |   2 +
 eeschema/sch_legacy_plugin.cpp| 217 --
 2 files changed, 180 insertions(+), 39 deletions(-)

diff --git a/common/kicad_curl/kicad_curl_easy.cpp b/common/kicad_curl/kicad_curl_easy.cpp
index 1e84afe..c1d4d24 100644
--- a/common/kicad_curl/kicad_curl_easy.cpp
+++ b/common/kicad_curl/kicad_curl_easy.cpp
@@ -61,6 +61,8 @@ KICAD_CURL_EASY::KICAD_CURL_EASY() :
 
 curl_easy_setopt( m_CURL, CURLOPT_WRITEFUNCTION, write_callback );
 curl_easy_setopt( m_CURL, CURLOPT_WRITEDATA, (void*) _buffer );
+// To be able to connect to a https server regardless the certificate issues
+curl_easy_setopt( m_CURL, CURLOPT_SSL_VERIFYHOST, 0L);
 }
 
 
diff --git a/eeschema/sch_legacy_plugin.cpp b/eeschema/sch_legacy_plugin.cpp
index 21def36..b0bb9ff 100644
--- a/eeschema/sch_legacy_plugin.cpp
+++ b/eeschema/sch_legacy_plugin.cpp
@@ -20,6 +20,8 @@
  * with this program.  If not, see .
  */
 
+#include  // Include before any wx file
+
 #include 
 #include 
 
@@ -140,7 +142,7 @@ static bool strCompare( const char* aString, const char* aLine, const char** aOu
  * @throws An #IO_ERROR on an unexpected end of line.
  * @throws A #PARSE_ERROR if the parsed token is not a valid integer.
  */
-static int parseInt( FILE_LINE_READER& aReader, const char* aLine, const char** aOutput = NULL )
+static int parseInt( LINE_READER& aReader, const char* aLine, const char** aOutput = NULL )
 {
 if( !*aLine )
 SCH_PARSE_ERROR( _( "unexpected end of line" ), aReader, aLine );
@@ -275,7 +277,7 @@ static double parseDouble( FILE_LINE_READER& aReader, const char* aLine,
  * @throws An #IO_ERROR on an unexpected end of line.
  * @throws A #PARSE_ERROR if the parsed token is not a a single character token.
  */
-static char parseChar( FILE_LINE_READER& aReader, const char* aCurrentToken,
+static char parseChar( LINE_READER& aReader, const char* aCurrentToken,
const char** aNextToken = NULL )
 {
 while( *aCurrentToken && isspace( *aCurrentToken ) )
@@ -317,7 +319,7 @@ static char parseChar( FILE_LINE_READER& aReader, const char* aCurrentToken,
  * @throws An #IO_ERROR on an unexpected end of line.
  * @throws A #PARSE_ERROR if the \a aCanBeEmpty is false and no string was parsed.
  */
-static void parseUnquotedString( wxString& aString, FILE_LINE_READER& aReader,
+static void parseUnquotedString( wxString& aString, LINE_READER& aReader,
  const char* aCurrentToken, const char** aNextToken = NULL,
  bool aCanBeEmpty = false )
 {
@@ -381,7 +383,7 @@ static void parseUnquotedString( wxString& aString, FILE_LINE_READER& aReader,
  * @throws An #IO_ERROR on an unexpected end of line.
  * @throws A #PARSE_ERROR if the \a aCanBeEmpty is false and no string was parsed.
  */
-static void parseQuotedString( wxString& aString, FILE_LINE_READER& aReader,
+static void parseQuotedString( wxString& aString, LINE_READER& aReader,
const char* aCurrentToken, const char**