Has anyone else been doing any testing? I have resolved some issues that
JP found, but haven't heard from anyone else.
-Jon
On Fri, Mar 22, 2019 at 5:08 PM Wayne Stambaugh
wrote:
> I did some testing and the changes appear to have resolved the original
> issues I found. One thing I did not
Hi Wayne,
On 29 March 2019 22:30:27 GMT, Wayne Stambaugh wrote:
>
> I don't know if I want to force this even though I think it's a good
> idea. So few of the source files in KiCad adhere to this that it would
> confuse new developers. However, devs should be aware of the issue.
Sure, it's
Hey John,
On 3/29/2019 9:44 AM, John Beard wrote:
> Hi Wayne,
>
> Duh, it's a Boost version thing, and I ran it though different
> platforms *except* the old-Boost one. Face, meet palm.
>
> Funnily enough, as this header is often included first, this one
> *should* be immune to ordering issues.
>> Maybe a better option would be to have footprint variations similar to
>> aliases.
>> Something with a new name, new 3d model path and new description but the
>> same land pattern.
This would be great and ease the libraries development quite a lot.
Diego
On Mon, Mar 25, 2019 at 8:50 PM Rene
Hi all,
I have pushed some changes to the format check git hook, which means
that when you commit with the hooks on:
* You won't be nagged about changes in generated files
* You won't be nagged about unstaged files
Also provide a handy fixer/checker/amender script that uses the same
logic and
JP,
On 3/27/19 4:12 PM, jp charras wrote:
> Le 20/03/2019 à 19:27, Wayne Stambaugh a écrit :
>> Hi JP,
>>
>> Rather than pollute the bug report[1] with feedback about your zone
>> hatch filling patch, I moved the conversation to the mailing list. If
>> anyone else would like to test and comment
Hi Wayne,
Duh, it's a Boost version thing, and I ran it though different
platforms *except* the old-Boost one. Face, meet palm.
Funnily enough, as this header is often included first, this one
*should* be immune to ordering issues.
Also, I sent a proposal for a modification to the Coding Policy
Hey John,
Thanks for the quick fix. It could be due to header ordering in the
source files. I generally try to compile the headers separately to
catch issues like this. There is helpful instructions in the coding
policy on how to do this. Given the number of headers included in the
KiCad
Hi Wayne,
Thanks for the heads up. I've pushed a fix to both branches. I'm not
sure why that ever worked silently on Linux GCC/Msys2 GCC/MSVC, but
using std:: is certainly correct. Perhaps a header has a sneaky type
alias somewhere.
Cheers,
John
On Fri, Mar 29, 2019 at 12:30 PM Wayne Stambaugh
Commit ad76ebd8 broke builds when compiling with clang.
home/wayne/src/kicad-trunk/qa/unit_test_utils/include/unit_test_utils/unit_test_utils.h:121:24:
error:
unknown type name 'nullptr_t'; did you mean 'std::nullptr_t'?
struct print_log_value
^
10 matches
Mail list logo
