kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #24465
Re: PATCH: 3D resolver
I knew you were kidding. If I didn't have to be concerned with anything
else, I would have committed the patch already and told everyone who
complained to pound sand. Unfortunately my role as product leader makes
things a bit more complicated. I'm with you on the c++11 side of
things. We'll get there eventually just not as quickly as I would like.
On 5/3/2016 10:05 AM, Chris Pavlina wrote:
> FWIW, I meant that to come across like I was kidding, and I'm not entirely sure
> I managed the right tone to get that across. I understand why you're cautious,
> though indeed I'm solidly on the pro-C++11 side of things ;)
>
> On Tue, May 03, 2016 at 09:49:14AM -0400, Wayne Stambaugh wrote:
>> On 5/2/2016 8:23 PM, Chris Pavlina wrote:
>>> On Mon, May 02, 2016 at 11:40:25AM -0400, Wayne Stambaugh wrote:
>>>> I'm not 100% sure we should pull the plug on mingw32/msys1 just yet.
>>>> There will most likely be a bunch ubuntu and fedora users who are using
>>>> older stable versions that this will effect as well. Personally I'm
>>>> fine with dumping these older platforms but our users may not feel the
>>>> same way. Anyone else have any thoughts about this?
>>>
>>> Y'all know *my* thoughts on the matter. >:) Which systems still require a
>>> non-C++11 compiler anyway? We don't even have to support Geriatric Giraffe
>>> anymore, there's a new LTS out... Debian supports C++11, Fedora supports C++11,
>>> we've got no problem building with it on Windows, OS X... So which elderly
>>> platforms could we possibly still be propping up at this point?
>>>
>>> Of course a few users won't like it, you can never make any change without
>>> ticking off a user or two. https://xkcd.com/1172/ comes to mind. But is
>>> supporting them worth the trouble?
>>>
>>> Seriously, come on - we *already* decided it wasn't, you already said we can
>>> switch to C++11. Then a bit over a month ago, we asked and you said we should
>>> be able to start making use of C++11 features in about a month or so. Is the
>>> C++11 cake a lie? ;)
>>
>> I just want to make sure everyone is one board with the potential shit
>> storm this could create. I know how most of the main devs feel about
>> c++11. I want to give everyone a heads up before I commit a change that
>> I know will break builds. I also am probably one of the few (possibly
>> only) devs that people outside the project will email directly when they
>> are pissed off. I've come to accept this since I am the project leader
>> and my email address is in the public domain but that doesn't mean I
>> have to like it so you can understand why I am cautious when committing
>> changes like this.
>>
>>>
>>>>
>>>> On 4/24/2016 2:06 AM, Cirilo Bernardo wrote:
>>>>> The attached patch fixes a cut/paste syntactic error present
>>>>> in all previous patches. A do{} block was changed to if{} but
>>>>> the while() expression at the end was not removed.
>>>>>
>>>>> - Cirilo
>>>>>
>>>>>
>>>>> On Sun, Apr 24, 2016 at 9:06 AM, Cirilo Bernardo
>>>>> <cirilo.bernardo@xxxxxxxxx <mailto:cirilo.bernardo@xxxxxxxxx>> wrote:
>>>>>
>>>>> The attached revised patch (against r6710) adds support for $(ENV_VAR)
>>>>> and fixes the bug reported by easyw: "invalid filename" on MSWin when
>>>>> manually editing a file name containing ${ENV_VAR}.
>>>>>
>>>>> - Cirilo
>>>>>
>>>>>
>>>>> On Sat, Apr 23, 2016 at 5:29 PM, jp charras <jp.charras@xxxxxxxxxx
>>>>> <mailto:jp.charras@xxxxxxxxxx>> wrote:
>>>>>
>>>>> Le 23/04/2016 09:16, Cirilo Bernardo a écrit :
>>>>> > Thanks Jean-Pierre, I'll go through the 3D model code and make sure it can
>>>>> > use "${" and "$(". I'm not sure about "%{", "%(" though since that wouldn't
>>>>> > be portable. In principle there can also be multiple substitutions and a
>>>>> > substitution in the middle of a string such as
>>>>> > "/path/${VAR1}/${VAR2}/model.wrl"
>>>>> > but I think the current system should work fine; if people do something else
>>>>> > they can be responsible for the resulting behavior.
>>>>> >
>>>>> > - Cirilo
>>>>>
>>>>> Supporting both "${" and "$(" is enough for me.
>>>>> If "${" is the starting point, "}" is the end of var name, and
>>>>> for "$(" the end of var name is ")"
>>>>>
>>>>>
>>>>> >
>>>>> > On Sat, Apr 23, 2016 at 4:28 PM, jp charras
>>>>> <jp.charras@xxxxxxxxxx <mailto:jp.charras@xxxxxxxxxx>> wrote:
>>>>> >
>>>>> >> Le 23/04/2016 01:29, Cirilo Bernardo a écrit :
>>>>> >>> Hi Wayne,
>>>>> >>>
>>>>> >>> The attached patch was made against r6709.
>>>>> >>>
>>>>> >>> - Cirilo
>>>>> >>
>>>>> >> Cirilo, I just had a look at the patch, and noticed a (minor)
>>>>> issue:
>>>>> >> you are searching an ENV VAR by searching "${"
>>>>> >>
>>>>> >> This is perfectly true, but incomplete.
>>>>> >> wxWidgets accepts both "${" and "$(". (and on windows accept
>>>>> also "%{" and
>>>>> >> "%(" and more)
>>>>> >> The delimiters can be { and } or ( and )
>>>>> >> They are equivalent in wxWidgets, and allows using ) or } in
>>>>> paths
>>>>> >>
>>>>> >> (have a look at wxString wxExpandEnvVars(const wxString& str) in
>>>>> >> src/common/config.cpp, perhaps it
>>>>> >> could be used )
>>>>> >>
>>>>> >>
>>>>> >> This in important because we are using both in Kicad.
>>>>> >> for instance the fp lib wizard uses $(xxx) and in docs we use
>>>>> ${xxx}
>>>>> >> notation
>>>>> >>
>>>>> >> Thanks.
>>>>> >>
>>>>> >>>
>>>>> >>>
>>>>> >>> On Sat, Apr 23, 2016 at 12:52 AM, Wayne Stambaugh
>>>>> <stambaughw@xxxxxxxxx <mailto:stambaughw@xxxxxxxxx>>
>>>>> >>> wrote:
>>>>> >>>
>>>>> >>>> Cirilo,
>>>>> >>>>
>>>>> >>>> This patch no longer applies cleanly. Would you please fix
>>>>> it an repost
>>>>> >>>> it.
>>>>> >>>>
>>>>> >>>> Thanks,
>>>>> >>>>
>>>>> >>>> Wayne
>>>>> >>>>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Jean-Pierre CHARRAS
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Mailing list: https://launchpad.net/~kicad-developers
>>>>> >> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>>>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> >> More help : https://help.launchpad.net/ListHelp
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Jean-Pierre CHARRAS
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help : https://help.launchpad.net/ListHelp
Follow ups
References
-
Re: PATCH: 3D resolver
From: Wayne Stambaugh, 2016-04-22
-
Re: PATCH: 3D resolver
From: Cirilo Bernardo, 2016-04-22
-
Re: PATCH: 3D resolver
From: jp charras, 2016-04-23
-
Re: PATCH: 3D resolver
From: Cirilo Bernardo, 2016-04-23
-
Re: PATCH: 3D resolver
From: jp charras, 2016-04-23
-
Re: PATCH: 3D resolver
From: Cirilo Bernardo, 2016-04-23
-
Re: PATCH: 3D resolver
From: Cirilo Bernardo, 2016-04-24
-
Re: PATCH: 3D resolver
From: Wayne Stambaugh, 2016-05-02
-
Re: PATCH: 3D resolver
From: Chris Pavlina, 2016-05-03
-
Re: PATCH: 3D resolver
From: Wayne Stambaugh, 2016-05-03
-
Re: PATCH: 3D resolver
From: Chris Pavlina, 2016-05-03