date:20201111

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

2020-11-11 Thread 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] MSYS2 Dropping 32-bit support

2020-11-11 Thread Nick Østergaard

Correct, but that is not the case right now. It just means that we should
be able to update MSYS2 packages just fine without trouble on the builder
server.

On Wed, 11 Nov 2020 at 13:30, Mark Roszko  wrote:

> >It does mention that it is just the environment that is 64 bit only, but
> not the mingw toolchains, so I don't really think this affects us.
>
> It does,* just not right now. *The writing is on the wall for 32-bit x86.
> Microsoft officially has marked 32-bit Windows 10 EOL and I believe it's
> being dropped by Microsoft towards the end of next year (no more security
> updates).
> It would be crazy for MSYS2 not to eventually drop the packages themselves
> as well.
>
> On Tue, Nov 10, 2020 at 6:13 PM Nick Østergaard  wrote:
>
>> On further review of the msys2 news page that states:
>>
>> /quote
>> 2020-05-17 - 32-bit MSYS2 no longer actively supported
>> 32-bit mingw-w64 packages are still supported, this is about the POSIX
>> emulation layer, i.e. the runtime, Bash, MinTTY...
>>
>> After this date, we don't plan on building updated msys-i686 packages nor
>> releasing i686 installers anymore. This is due to increasingly frustrating
>> difficulties with limited 32-bit address space, high penetration of 64-bit
>> systems and Cygwin (our upstream) starting their way to drop 32-bit support
>> as well.
>> /quote
>>
>> It does mention that it is just the environment that is 64 bit only, but
>> not the mingw toolchains, so I don't really think this affects us.
>>
>> Nick
>>
>> On Wed, 5 Aug 2020 at 01:10, Wayne Stambaugh 
>> wrote:
>>
>>> On 8/4/20 4:43 PM, Seth Hillbrand wrote:
>>> >
>>> >
>>> > On Tue, Aug 4, 2020 at 4:41 AM Wayne Stambaugh >> > > wrote:
>>> >
>>> > On 8/3/20 9:19 PM, Seth Hillbrand wrote:
>>> > >
>>> > >
>>> > > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh
>>> > mailto:stambau...@gmail.com>
>>> > > >>
>>> wrote:
>>> > >
>>> > > I'm not ready to drop 32 bit builds for V6.  I still think
>>> > there are
>>> > > enough 32-bit users to warrant supporting it for one more
>>> > release.  It's
>>> > > something we can discuss for V7.
>>> > >
>>> > >
>>> > > If we keep 32 bit builds on mingw2, does that mean that we
>>> freeze all
>>> > > packages at their current versions?  It might be problematic to
>>> keep
>>> > > different package versions for different architectures.
>>> >
>>> > I'm assuming you mean dependency packages so yes we would continue
>>> to
>>> > build 32 bit windows versions using the current package versions.
>>> If
>>> > someone figures out how to get wxPhoenix to build, then we could
>>> bump to
>>> > wxWidgets 3.1.x and Python 3.x.
>>> >
>>> >
>>> > Do you envision building 32-bit and 64-bit with different package
>>> versions?
>>>
>>> I hope not but we may have to bite the bullet if we can't get all of the
>>> packaging up to snuff be it msys2 or msvc builds.
>>>
>>> >
>>> > -Seth
>>> >
>>> >
>>> > --
>>> > KiCad Services Corporation Logo
>>> > Seth Hillbrand
>>> > *Lead Developer*
>>> > +1-530-302-5483‬ 
>>> > Davis, CA
>>> > www.kipro-pcb.com i...@kipro-pcb.com
>>> > 
>>> >
>>>
>>> ___
>>> 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
>>
>
>
> --
> Mark
>
___
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] MSYS2 Dropping 32-bit support

2020-11-11 Thread Mark Roszko

>It does mention that it is just the environment that is 64 bit only, but
not the mingw toolchains, so I don't really think this affects us.

It does,* just not right now. *The writing is on the wall for 32-bit x86.
Microsoft officially has marked 32-bit Windows 10 EOL and I believe it's
being dropped by Microsoft towards the end of next year (no more security
updates).
It would be crazy for MSYS2 not to eventually drop the packages themselves
as well.

On Tue, Nov 10, 2020 at 6:13 PM Nick Østergaard  wrote:

> On further review of the msys2 news page that states:
>
> /quote
> 2020-05-17 - 32-bit MSYS2 no longer actively supported
> 32-bit mingw-w64 packages are still supported, this is about the POSIX
> emulation layer, i.e. the runtime, Bash, MinTTY...
>
> After this date, we don't plan on building updated msys-i686 packages nor
> releasing i686 installers anymore. This is due to increasingly frustrating
> difficulties with limited 32-bit address space, high penetration of 64-bit
> systems and Cygwin (our upstream) starting their way to drop 32-bit support
> as well.
> /quote
>
> It does mention that it is just the environment that is 64 bit only, but
> not the mingw toolchains, so I don't really think this affects us.
>
> Nick
>
> On Wed, 5 Aug 2020 at 01:10, Wayne Stambaugh  wrote:
>
>> On 8/4/20 4:43 PM, Seth Hillbrand wrote:
>> >
>> >
>> > On Tue, Aug 4, 2020 at 4:41 AM Wayne Stambaugh > > > wrote:
>> >
>> > On 8/3/20 9:19 PM, Seth Hillbrand wrote:
>> > >
>> > >
>> > > On Mon, Aug 3, 2020, 10:48 AM Wayne Stambaugh
>> > mailto:stambau...@gmail.com>
>> > > >>
>> wrote:
>> > >
>> > > I'm not ready to drop 32 bit builds for V6.  I still think
>> > there are
>> > > enough 32-bit users to warrant supporting it for one more
>> > release.  It's
>> > > something we can discuss for V7.
>> > >
>> > >
>> > > If we keep 32 bit builds on mingw2, does that mean that we freeze
>> all
>> > > packages at their current versions?  It might be problematic to
>> keep
>> > > different package versions for different architectures.
>> >
>> > I'm assuming you mean dependency packages so yes we would continue
>> to
>> > build 32 bit windows versions using the current package versions.
>> If
>> > someone figures out how to get wxPhoenix to build, then we could
>> bump to
>> > wxWidgets 3.1.x and Python 3.x.
>> >
>> >
>> > Do you envision building 32-bit and 64-bit with different package
>> versions?
>>
>> I hope not but we may have to bite the bullet if we can't get all of the
>> packaging up to snuff be it msys2 or msvc builds.
>>
>> >
>> > -Seth
>> >
>> >
>> > --
>> > KiCad Services Corporation Logo
>> > Seth Hillbrand
>> > *Lead Developer*
>> > +1-530-302-5483‬ 
>> > Davis, CA
>> > www.kipro-pcb.com i...@kipro-pcb.com
>> > 
>> >
>>
>> ___
>> 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
>


-- 
Mark
___
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

Re: [Kicad-developers] MSYS2 Dropping 32-bit support

Re: [Kicad-developers] MSYS2 Dropping 32-bit support

3 matches

Site Navigation

Mail list logo

Footer information