@Brecht Van Lommel (brecht), looks like you updated python to 3.5.3 but didn't rebuild numpy , mind taking a quick peek here?

Cleanup looks all-right, doesn't break any tests, be sure not to commit those new line changes, beyond that lgtm

so 2.78c is fine, but the builds from builder.blender.org crash?

anaconda is open data science platform ( https://www.continuum.io/downloads ) that also uses python, but sometimes their setup interferes with our libraries.

there's a command line switch for that , blender --factory-startup

Strange.... if you grab a nightly from https://builder.blender.org/download/ same thing?

it's an internal path inside an alembic file, we should not impose any OS related restrictions to that in the first place?

What happens if you switch to the python console and type

numpy seems fine here, I need better repro steps , what addin is being installed? what version of blender is this on etc? marking as incomplete until more information is supplied.

after some convincing i had the release build put out a stracktrace

After some more testing, i got the buildbot and my local release version to crash, but not my debug build... :(

Yes, used a 2015/x64 buildbot from yesterday, and and build (2015/x64/debug) from master today.

for what it's worth, i can't repro on win7, with either the buildbot or my own builds....

That's the last one in my list

I enabled the paged heap (it's kinda like asan lite, it tends to bring out crashes) and tried

this one is yours i suppose @Lukas Stockner (lukasstockner97) ?

I give it some spit and polish, tested it as far as i can without a system glew lib, but i'm pretty sure this is pretty close to what it needs to be..

Oh i'm not suggesting removing the check, i think we should just have another stab at seeing if we can cmake do it, cause we made the change to core only a few hours ago, and it's already causing issues with tech savvy end users who do their own builds.

I just had to talk someone on irc through why blender build successfully but at runtime bailed out over the glew version, i would really really really like this to be a configure time cmake check.

Use Window->Toggle console to display the console, it'll tell you you are mixing tabs and spaces

@Mike Erwin (merwin) here's some low hanging fruit, didn't want to commit without you looking at it.

1. You filled out none of the required information (OS, blender version etc...) , so please complete your report with this information.

The repo seems fine ( I'm cloning from canada at +- 1.77 MiB/s ) ,maybe it's a local routing issue?

This is a general support issue and not a software error we can investigate.

This is a general support issue and not a software error we can investigate.

I took a quick peek at the code, everything indicates this should be working, but it's not. @Mike Erwin (merwin) mind taking a quick peek here?

Seems allright in rendered view? material view they are all blue indeed.

Seems to be working fine, please attach a .blend demonstrating the problem

All tests pass in the temp branch! looks like those changes are good to go!

I resolved point 3 in svn, all flavors of the windows libs now have the binary tools, all others i'm gonna leave up to you , just poke me on irc if you need something tested

Windows keeps a copy of most installers in c:\windows\installer if that folder gets corrupted or deleted after you installed 2.78a, it will indeed still ask for the 2.78a msi when you install 2.78c that's just how the system works, not something we can change.

Regardless if it's easy or not, i would really prefer if we did not store a giant cache of users passwords in clear text. might have been ok 10 years ago, but right now it's just bad security practice

Updated with feeback from @Sergey Sharybin (sergey)

if the object path can be arbitrarily large it's gonna be a matter of time before someone comes with a file with 4097 byte object path, why not just allocate the ram you need?

known issue in 2.78a fixed in later versions.

I think the main issue for mingw support it's the 3rd party deps, nobody has stepped up in years to care for them. understandably so, this is the patchset just to be able to build python with mingw. It's not impossible to do, someone just has to step up. That being said, if someone were to step up, it's probably easier to bring back mingw support from a completely removed state than a neglected for years state. so +1 for the removal of it.

In D2573#62077, @Aaron Carlisle (Blendify) wrote:

@LazyDodo (LazyDodo) if I am correct the issue is in MSVC 2015 but 2017 does not have this issue? Maybe it is just better and move directly to MSVC 2017?

last warning: STOP CHANGING THE STATUS AND PRIORITY FIELDS

1. That's not an addon.
2. It's 3rd party code we cannot offer support on
3. The author even has a video tutorial on how to install his code... https://github.com/GoranM/sprycle

try (re)installing the nvidia drivers any how, this has worked for previous issues on windows 10 with nvidia.

In T51262#429683, @Sybren A. Stüvel (sybren) wrote:

Then attach the crashing file to this ticket, otherwise we can't investigate the issue.

stop doing that

1. If the problem is with an .obj file, attach the .obj file so we can reproduce the problem
2. Judging from your error message, it looks like you have a nan in your .obj file, and blender is correct for rejecting it, the issue should probably be solved by the application that wrote the .obj file
3. please refrain from assigning priority your self, we'll triage the ticket once we have enough information about the bug and assign an appropriate priority.

Please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Given i wasn't able to repro with master in december, i'm pretty sure @Kévin Dietrich (kevindietrich) fixed this one before you took over.

EXCEPTION_IN_PAGE_ERROR tend to be hardware malfunctions, failing drive, bad ram, overheating cpu etc, it's not a fault in blender or something we can fix.

D2605 is the way to go.

redid the code changes with notepad , to make sure vs didn't ruin the codestyle.

I haven't validated the output, however the results look great!

After some profiling i'm seeing some further optimizations that might give some further gains, holding off on fighting this particular battle until i have some new numbers.

That argument only works one way, you have all windows devs saving 2 minutes/full builds on daily basis, vs that one guy that's going to lose 1 minute going why is my debugger so whacky!? looks at the top of the file or the cmakelist to figure out what's going on and why in the rare event this code needs work (6 commits in 4 years)

no longer happens in master, i assume the landing of D1574 fixed it.

In D2601#60906, @Sergey Sharybin (sergey) wrote:

I am not happy at all with such a tricks to force particular targets to be release. If one requests Blender to be in debug mode, it should be so. Unrelated how often one debugs the code.

I'm not a big fan either, however a with 29x speedup in runtime, (18.7x with rBe4c5441286f) and nearly 8% reduction in global build time, I'm willing to change my mind quite rapidly ,at this point i'm willing to consider who we're punishing (all windows devs) by not doing it, and who might be negatively impacted by these changes (lets be honest, git blame reveals..... it's just you, and you're not even on this platform 99.9% of the time) , so based on that information I decided to propose this change.

missed one.