Date: Thu, 05 Apr 2018 15:49:28 +0000
Tooling works more reliably in the face of code that is more well-behaved.
It's going to have to be a two-way street: we provide more guidance for
good practices so that users do fewer weird things (#include'ing private
.cc files), and we try to improve the robustness of the tools in question.
In theory, none of this is possible because of the arbitrary bad things
that users can do with the preprocessor. In practice, it turns out to work
reasonably from what I've seen.
We will *not* have any success defining a new build system. But we may have
some success defining best practices for producing toolable code.
It would be best to have some sort of practical test case to validate
against: some fraction of common github projects or the like. But we need
to find paths to move from discussion to action.
On Wed, Apr 4, 2018 at 3:17 AM Corentin <corentin.jabot_at_[hidden]> wrote:
> But that's specifically why I think current tooling don't work reliably.
> Of course compilers are seeing the code a certain way.
> But developers work on all of the code. A project being a cohesive set of
> files.
> There should be ( on new code ) no need for any more external information
> that "this is a set of files".
> Point the tool towards a directory and refactor to you heart content.
> Build systems are extremely important but should not be necessary for
> anything but building.
>
> Indexing, symbol renaming, doc generation, etc should probably not require
> a full blown build system to work.
> And it should work on the code rather than a partial, incomplete view of
> the code.
> Do we really think sidestepping this issue by running the tool for each
> known configuration ( a number which explodes exponentially as you
> mentioned) is a satisfactory long term solution ?
>
> Can we make source files self-sufficient sources of truth ? That's a goal
> I would like to see explored.
>
> We of course agree that tooling implies having a solid continuous
> integration / test suite.
>
>
> PS : I didn't receive Gaby's email either.
>
>
> Le mer. 4 avr. 2018 à 08:31, Peter Sommerlad <peter.sommerlad_at_[hidden]> a
> écrit :
>
>> Another CHF0.02:
>>
>> One important aspect for all kind of tooling is to have a way what
>> consists of a 'build' or project. A lot of tooling as well as IDE suffer
>> from the user experience for setting up a 'project' and get all settings
>> correctly, so that tools see the same code in the same way as the ultimate
>> compiler and linker are seeing it. The separate compilation model inherited
>> from C that was rooted in the limited hardware platforms of the 1970s might
>> no longer be appropriate, but separation of work is still important.
>>
>> May be this should even be a short term goal to standardize:
>> * what makes the whole executable program/object code?
>> * what build modes exist for a specific chunk of code? How do they
>> combine with other chunks' build modes? How to reign the explosion of
>> potential combinations to a practical limit?
>>
>> Regards
>> Peter
>>
>>
>>
>> Sent from Peter Sommerlad's iPad
>> +41 79 432 23 32 <+41%2079%20432%2023%2032>
>>
>> On 4 Apr 2018, at 02:03, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>>
>> I will add my piece about long term goals later, but I just want to
>> emphasize Titus here:
>>
>>
>>
>> - Refactoring isn't near impossible, it's just hard.
>>
>>
>>
>> Absolutely.
>>
>> It would a fundamental mistake for SG15 to make, and WG21 to copy, in
>> thinking that a tooling capability is an issue only if it is (nearly)
>> impossible. If we are making something hard, or harder, we must think
>> twice. Or thrice. When you make tooling harder, you are potentially
>> reducing its availability. Think about it.
>>
>>
>>
>> -- Gaby
>>
>>
>>
>> *From:* tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> *On
>> Behalf Of *Titus Winters
>> *Sent:* Tuesday, April 3, 2018 12:40 PM
>> *To:* WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>> *Subject:* Re: [Tooling] Proposed mission
>>
>>
>>
>> Refactoring isn't near impossible, it's just hard. (See most of the
>> talks that Google has given at CppCon for the last few years - there's
>> massive refactoring mentioned in most or all of 'em.)
>>
>>
>>
>> Macros are hard, but not that hard. Inappropriate/unsupported usage of
>> an API causes far more pain - you can see stories about that in
>> https://www.youtube.com/watch?v=u5senBJUkPc
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Du5senBJUkPc&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=KJzWRGPGtoEIGcriui98rY8UJHYMDh1L3vWDHEKiA9s%3D&reserved=0> or
>> the rules we've had to come up with in Abseil compatibility (
>> https://abseil.io/about/compatibility
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fabseil.io%2Fabout%2Fcompatibility&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=f%2FeQeCrCSGhRdCpRd3j1dCKZGNDV%2BwqsLh47QZIhCa8%3D&reserved=0>)
>> or my proposal at the standards level (http://wg21.link/p0921
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp0921&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=F%2F45MhDyhdAcjLvElRHDM7fMzP2NPd9TmAdH2us9mEY%3D&reserved=0>).
>> But the tools we rely upon internally work because we control the build
>> system and toolchain. If an arbitrary project's build isn't understandable,
>> tools won't work. Similarly, if a project is deeply dependent on the quirks
>> of a single compiler and that vendor doesn't provide refactoring tools,
>> then we (as the committee or as the community) cannot rely on the existence
>> of those tools.
>>
>>
>>
>> But all of that is fairly tactical - I'd really like to think about this
>> as a far bigger picture thing. Setting a good long-term mission that gets
>> us all of these shorter-term goals as a side effect is a good way to
>> structure things - if we agree on the long term, then minor chaos in the
>> short term still leads us in the right direction without getting too hung
>> up on people's differences in priorities for tactical decisions.
>>
>>
>>
>> On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]> wrote:
>>
>> I wasn't at Jacksonville.
>>
>> Were the current issues discussed ?
>>
>> Aka what makes refactoring near-impossible today ?
>>
>> Of course, I have an answer to that ( macros ) - but it's probably not
>> the only pain point.
>>
>>
>>
>> I don't believe anything added after 98 made things fundamentally more
>> complicated for tools.
>>
>> (Exporting-macro modules might...)
>>
>>
>>
>> Once we identify the actual pain points it will be easier to work around
>> them.
>>
>> Probably by introducing new language constructs - Lots of very smart
>> people tried to make refactoring work over the past 30 years, I don't
>> believe SG15 can improve on the state of the art without taking a
>> completely new approach.
>>
>>
>>
>> So, here is an attempt to reformulate Titus' goal:
>>
>>
>>
>> Refactoring tools that people can trust blindly. (either because the tool
>> works 100% of the time or notifies the user about 100% of the failure
>> cases).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :
>>
>> Hi Titus,
>>
>>
>>
>> While I think this is a great long-term mission, I believe this leaves
>> out a big area where SG15 can provide value today, in the more immediate
>> term.
>>
>>
>>
>> I believe we should spend some time on questions like:
>>
>>
>>
>> - What language features, that WG21 is working on today, make it harder
>> (or easier) to write good tools for?
>>
>> - Are there areas where SG15 can provide guidance to WG21? Think about
>> this scenario. New shiny language feature X has two possible design
>> directions, A and B. Both seem to solve the problem similarly well.
>> However, direction A would create a major pain-in-the-butt for tools
>> vendors, whereas direction B wouldn’t. Should we not monitor, detect, and
>> discuss such cases and then feed our insights back into WG21?
>>
>> - Are there areas where, instead of adding more stuff to C++, the problem
>> would be more adequately solved with tooling?
>>
>> - Are there areas where language features pose significant challenges for
>> tool vendors, and where it could be good for everyone if we had a platform
>> to synchronise on those challenges? (*cough* *cough* modules *cough*)
>>
>>
>>
>> Cheers,
>>
>> Timur
>>
>>
>>
>>
>>
>> On 2 Apr 2018, at 21:08, Titus Winters <titus_at_[hidden]> wrote:
>>
>>
>>
>> At the recent evening session in Jacksonville, many many things were
>> brought up in the realm of "tooling." These ranged all across the spectrum
>> of engineering tools, from IDE support, dependency management / discovery,
>> distribution, refactoring, and a host of other things.
>>
>>
>>
>> On the fly, I tried to cobble those into a coherent goal for SG15 and the
>> committee to aim toward. It's currently phrased very much for the
>> committee audience (that's been part of my delay in re-summarizing here),
>> but as with any good mission statement I think it gets direction and
>> incentive structures aligned with the greater good. Put another way: it's
>> phrased selfishly, but hopefully produces great results for the entire
>> community.
>>
>>
>>
>> So, here is that proposed mission statement:
>>
>>
>>
>> In 10 years, the committee should be able to run compiler-informed
>> queries against a significant fraction of the open-source C++ community and
>> use that to inform deployment of refactoring tools to mitigate.
>>
>> - Consistent build understanding
>> - Consistent package distribution / identification
>> - Provide static analysis and refactoring to help provide users easy
>> upgrades and modernization
>>
>>
>>
>> Obviously this would be a huge task that requires support from many
>> chunks of the community - WG21 cannot be solely responsible, and it's
>> outside of what WG21 is normally great at. But we can help set direction,
>> plan, prioritize, and lend support to ideas that emerge along these lines.
>>
>>
>>
>> So, I'd like to hear from everyone a bit: is this a good direction? Does
>> it capture what we'd like? Can we phrase it less selfishly?
>>
>>
>>
>> If we're happy with holding this up as the long-term goal, we'll need to
>> break it down into more manageable pieces. I've privately asked a couple
>> people to sketch out what they envision it would take to get from where we
>> are to that proposed future. I'd like to broaden that call, and we'll look
>> collectively at those break-downs to try to formulate next steps.
>>
>>
>>
>> Thoughts?
>>
>> -Titus
>>
>>
>>
>> PS: I've also just completed a big round of offloading in my day job, so
>> hopefully I'll have more cycles to pay attention to discussion on this
>> list. My apologies for my scattered attention so far.
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
It's going to have to be a two-way street: we provide more guidance for
good practices so that users do fewer weird things (#include'ing private
.cc files), and we try to improve the robustness of the tools in question.
In theory, none of this is possible because of the arbitrary bad things
that users can do with the preprocessor. In practice, it turns out to work
reasonably from what I've seen.
We will *not* have any success defining a new build system. But we may have
some success defining best practices for producing toolable code.
It would be best to have some sort of practical test case to validate
against: some fraction of common github projects or the like. But we need
to find paths to move from discussion to action.
On Wed, Apr 4, 2018 at 3:17 AM Corentin <corentin.jabot_at_[hidden]> wrote:
> But that's specifically why I think current tooling don't work reliably.
> Of course compilers are seeing the code a certain way.
> But developers work on all of the code. A project being a cohesive set of
> files.
> There should be ( on new code ) no need for any more external information
> that "this is a set of files".
> Point the tool towards a directory and refactor to you heart content.
> Build systems are extremely important but should not be necessary for
> anything but building.
>
> Indexing, symbol renaming, doc generation, etc should probably not require
> a full blown build system to work.
> And it should work on the code rather than a partial, incomplete view of
> the code.
> Do we really think sidestepping this issue by running the tool for each
> known configuration ( a number which explodes exponentially as you
> mentioned) is a satisfactory long term solution ?
>
> Can we make source files self-sufficient sources of truth ? That's a goal
> I would like to see explored.
>
> We of course agree that tooling implies having a solid continuous
> integration / test suite.
>
>
> PS : I didn't receive Gaby's email either.
>
>
> Le mer. 4 avr. 2018 à 08:31, Peter Sommerlad <peter.sommerlad_at_[hidden]> a
> écrit :
>
>> Another CHF0.02:
>>
>> One important aspect for all kind of tooling is to have a way what
>> consists of a 'build' or project. A lot of tooling as well as IDE suffer
>> from the user experience for setting up a 'project' and get all settings
>> correctly, so that tools see the same code in the same way as the ultimate
>> compiler and linker are seeing it. The separate compilation model inherited
>> from C that was rooted in the limited hardware platforms of the 1970s might
>> no longer be appropriate, but separation of work is still important.
>>
>> May be this should even be a short term goal to standardize:
>> * what makes the whole executable program/object code?
>> * what build modes exist for a specific chunk of code? How do they
>> combine with other chunks' build modes? How to reign the explosion of
>> potential combinations to a practical limit?
>>
>> Regards
>> Peter
>>
>>
>>
>> Sent from Peter Sommerlad's iPad
>> +41 79 432 23 32 <+41%2079%20432%2023%2032>
>>
>> On 4 Apr 2018, at 02:03, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>>
>> I will add my piece about long term goals later, but I just want to
>> emphasize Titus here:
>>
>>
>>
>> - Refactoring isn't near impossible, it's just hard.
>>
>>
>>
>> Absolutely.
>>
>> It would a fundamental mistake for SG15 to make, and WG21 to copy, in
>> thinking that a tooling capability is an issue only if it is (nearly)
>> impossible. If we are making something hard, or harder, we must think
>> twice. Or thrice. When you make tooling harder, you are potentially
>> reducing its availability. Think about it.
>>
>>
>>
>> -- Gaby
>>
>>
>>
>> *From:* tooling-bounces_at_[hidden] <tooling-bounces_at_[hidden]> *On
>> Behalf Of *Titus Winters
>> *Sent:* Tuesday, April 3, 2018 12:40 PM
>> *To:* WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
>> *Subject:* Re: [Tooling] Proposed mission
>>
>>
>>
>> Refactoring isn't near impossible, it's just hard. (See most of the
>> talks that Google has given at CppCon for the last few years - there's
>> massive refactoring mentioned in most or all of 'em.)
>>
>>
>>
>> Macros are hard, but not that hard. Inappropriate/unsupported usage of
>> an API causes far more pain - you can see stories about that in
>> https://www.youtube.com/watch?v=u5senBJUkPc
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Du5senBJUkPc&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=KJzWRGPGtoEIGcriui98rY8UJHYMDh1L3vWDHEKiA9s%3D&reserved=0> or
>> the rules we've had to come up with in Abseil compatibility (
>> https://abseil.io/about/compatibility
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fabseil.io%2Fabout%2Fcompatibility&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=f%2FeQeCrCSGhRdCpRd3j1dCKZGNDV%2BwqsLh47QZIhCa8%3D&reserved=0>)
>> or my proposal at the standards level (http://wg21.link/p0921
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwg21.link%2Fp0921&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=F%2F45MhDyhdAcjLvElRHDM7fMzP2NPd9TmAdH2us9mEY%3D&reserved=0>).
>> But the tools we rely upon internally work because we control the build
>> system and toolchain. If an arbitrary project's build isn't understandable,
>> tools won't work. Similarly, if a project is deeply dependent on the quirks
>> of a single compiler and that vendor doesn't provide refactoring tools,
>> then we (as the committee or as the community) cannot rely on the existence
>> of those tools.
>>
>>
>>
>> But all of that is fairly tactical - I'd really like to think about this
>> as a far bigger picture thing. Setting a good long-term mission that gets
>> us all of these shorter-term goals as a side effect is a good way to
>> structure things - if we agree on the long term, then minor chaos in the
>> short term still leads us in the right direction without getting too hung
>> up on people's differences in priorities for tactical decisions.
>>
>>
>>
>> On Tue, Apr 3, 2018 at 2:32 PM Corentin <corentin.jabot_at_[hidden]> wrote:
>>
>> I wasn't at Jacksonville.
>>
>> Were the current issues discussed ?
>>
>> Aka what makes refactoring near-impossible today ?
>>
>> Of course, I have an answer to that ( macros ) - but it's probably not
>> the only pain point.
>>
>>
>>
>> I don't believe anything added after 98 made things fundamentally more
>> complicated for tools.
>>
>> (Exporting-macro modules might...)
>>
>>
>>
>> Once we identify the actual pain points it will be easier to work around
>> them.
>>
>> Probably by introducing new language constructs - Lots of very smart
>> people tried to make refactoring work over the past 30 years, I don't
>> believe SG15 can improve on the state of the art without taking a
>> completely new approach.
>>
>>
>>
>> So, here is an attempt to reformulate Titus' goal:
>>
>>
>>
>> Refactoring tools that people can trust blindly. (either because the tool
>> works 100% of the time or notifies the user about 100% of the failure
>> cases).
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Le lun. 2 avr. 2018 à 22:08, Timur Doumler <cpp_at_[hidden]> a écrit :
>>
>> Hi Titus,
>>
>>
>>
>> While I think this is a great long-term mission, I believe this leaves
>> out a big area where SG15 can provide value today, in the more immediate
>> term.
>>
>>
>>
>> I believe we should spend some time on questions like:
>>
>>
>>
>> - What language features, that WG21 is working on today, make it harder
>> (or easier) to write good tools for?
>>
>> - Are there areas where SG15 can provide guidance to WG21? Think about
>> this scenario. New shiny language feature X has two possible design
>> directions, A and B. Both seem to solve the problem similarly well.
>> However, direction A would create a major pain-in-the-butt for tools
>> vendors, whereas direction B wouldn’t. Should we not monitor, detect, and
>> discuss such cases and then feed our insights back into WG21?
>>
>> - Are there areas where, instead of adding more stuff to C++, the problem
>> would be more adequately solved with tooling?
>>
>> - Are there areas where language features pose significant challenges for
>> tool vendors, and where it could be good for everyone if we had a platform
>> to synchronise on those challenges? (*cough* *cough* modules *cough*)
>>
>>
>>
>> Cheers,
>>
>> Timur
>>
>>
>>
>>
>>
>> On 2 Apr 2018, at 21:08, Titus Winters <titus_at_[hidden]> wrote:
>>
>>
>>
>> At the recent evening session in Jacksonville, many many things were
>> brought up in the realm of "tooling." These ranged all across the spectrum
>> of engineering tools, from IDE support, dependency management / discovery,
>> distribution, refactoring, and a host of other things.
>>
>>
>>
>> On the fly, I tried to cobble those into a coherent goal for SG15 and the
>> committee to aim toward. It's currently phrased very much for the
>> committee audience (that's been part of my delay in re-summarizing here),
>> but as with any good mission statement I think it gets direction and
>> incentive structures aligned with the greater good. Put another way: it's
>> phrased selfishly, but hopefully produces great results for the entire
>> community.
>>
>>
>>
>> So, here is that proposed mission statement:
>>
>>
>>
>> In 10 years, the committee should be able to run compiler-informed
>> queries against a significant fraction of the open-source C++ community and
>> use that to inform deployment of refactoring tools to mitigate.
>>
>> - Consistent build understanding
>> - Consistent package distribution / identification
>> - Provide static analysis and refactoring to help provide users easy
>> upgrades and modernization
>>
>>
>>
>> Obviously this would be a huge task that requires support from many
>> chunks of the community - WG21 cannot be solely responsible, and it's
>> outside of what WG21 is normally great at. But we can help set direction,
>> plan, prioritize, and lend support to ideas that emerge along these lines.
>>
>>
>>
>> So, I'd like to hear from everyone a bit: is this a good direction? Does
>> it capture what we'd like? Can we phrase it less selfishly?
>>
>>
>>
>> If we're happy with holding this up as the long-term goal, we'll need to
>> break it down into more manageable pieces. I've privately asked a couple
>> people to sketch out what they envision it would take to get from where we
>> are to that proposed future. I'd like to broaden that call, and we'll look
>> collectively at those break-downs to try to formulate next steps.
>>
>>
>>
>> Thoughts?
>>
>> -Titus
>>
>>
>>
>> PS: I've also just completed a big round of offloading in my day job, so
>> hopefully I'll have more cycles to pay attention to discussion on this
>> list. My apologies for my scattered attention so far.
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7Caf4dfe1ed52f4a49e47308d5999aac2c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636583811954972136&sdata=SQ54mcv5q5n5tSJzpLy6Cl5azaR2XG0a7J8GSYpi3WA%3D&reserved=0>
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>
Received on 2018-04-05 17:49:41