Re: [Bf-committers] trying to build with mingw32
I see there is an updated installer on MinGW site. I will test in case something breaks. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] trying to build with mingw32
Well I'll be darned! They did forget to include gcc...facepalm Yousef, can you try this installer instead? http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-2018/ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
I should mention that PVS-Studio contains clang for C++ parsing and preprocessing. As far I can see they have reimplemented some of the clang features (missing in vc++) and have added their own diagnosis patterns. The main feature is visual studio integration, which allows to enable/disable diagnosis options and mark false positives right inside visual studio using GUI. The drawback is impossibility of using it even with VC++ Express Edition (this version does not support extension packages) and of course with non-windows systems. The price of €3500/year also worries me. Be sure not to lock in to a proprietary vendor when the license expires. so basically Andrey Karpov is selling better version of Clang (at least better than native vc++ compiler analyser). But remember 3DMagix and IllusionMage? Of course PVS-Studio is NOT a such scam, but only because Clang is under BSD license and not GPL. The problem is PVS-Studio have never returned a single line of code back to the Clang SVN. As for me I do not support such kind of business. 25 апреля 2012 г. 9:44 пользователь Campbell Barton ideasma...@gmail.com написал: for obvious things they mostly find the same issues (even same false positives), but each have a handful that are unique. I've ran blender through cppcheck, splint, sparse and clang-static-checler. the problem is that once you wade through the error logs (mainly false positives), and fixed the actual bugs... Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. On Wed, Apr 25, 2012 at 9:30 AM, Nicholas Bishop nicholasbis...@gmail.com wrote: Not necessarily; different static analyzers can detect different types of potential problems. The PVS analysis contains some interesting things like the Misprint in a homogeneous code block section that I don't think clang's analyzer does. On Tue, Apr 24, 2012 at 7:20 PM, Tom M letter...@gmail.com wrote: We have a page with generated CLang static analysis, http://clang.blenderheads.org/trunk/ It probably shows the same bugs as PVS-Studio does. LetterRip On Tue, Apr 24, 2012 at 4:15 PM, Nicholas Bishop nicholasbis...@gmail.com wrote: I think some of these have been fixed already in recent commits from Campbell. On Tue, Apr 24, 2012 at 7:11 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: http://www.viva64.com/en/b/0145/#ID0EO3BK It appears that Andrey Karpov has done an analysis of Blender source code using his PVS-Studio tool. He did this just yesterday, so I assume the problems he found are still in the source. He offers free licenses to open source project members (3500 euro software otherwise, wow). I was thinking of investigating the problems he found and seeing if I could fix them. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] game engine without visual
Thanks for answer, uhm, can you please expline me the second possibility you wrote a bit more. I'm not really sure I do understand what to do. Thanks, Zbyněk Dne 24.4.2012 22:06, Campbell Barton napsal(a): Hi. there are a few ways you could that this, we have headless build option for ghost. - in cmake its WITH_HEADLESS, this builds a blender which does not link with X11 (or do any windowing). You could look at enabling this build flag and then adding ifdef's in the BGE to comment out drawing code. Another way would be to use G.background (or some BGE variable initialized from G.background) and have the BGE check for background, this has the advantage that you wouldn't need a custom build to take advantage of the feature. On Wed, Apr 25, 2012 at 4:26 AM, P2stap2...@atlas.cz wrote: Hello, I would like to know if it's possible to make the game run on the background (without any visual part). I mean when I hit start game button, I need only a physics to make collision detection, no rendering. Can anybody help me wtih that or at least give me some tips how to get this done? Thanks in advance, Zbyněk ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
I thought that he had his own tool viva64 that PVS-Studio was based on. I do not really want to argue politics, but I have no problem with the fact that he has added value by integrating it with VS and then released it without source. He honestly may not have even modified clang that much and is just using it as a library. The clang license was specifically chosen so that people could do this kind of thing. I really like the BSD style license :-) I also do not think you can get locked in to a tool like this. It checks your source for possible errors. If it stops working then you shrug your shoulders and move on. Microsoft will be releasing a checking tool as part of the next Visual Studio (even the Express version) and I look forward to having more tools to satisfy my nit-picking fetish :-) On Wed, Apr 25, 2012 at 3:35 AM, Lockal S lockals...@gmail.com wrote: I should mention that PVS-Studio contains clang for C++ parsing and preprocessing. As far I can see they have reimplemented some of the clang features (missing in vc++) and have added their own diagnosis patterns. The main feature is visual studio integration, which allows to enable/disable diagnosis options and mark false positives right inside visual studio using GUI. The drawback is impossibility of using it even with VC++ Express Edition (this version does not support extension packages) and of course with non-windows systems. The price of EURO 3500/year also worries me. Be sure not to lock in to a proprietary vendor when the license expires. so basically Andrey Karpov is selling better version of Clang (at least better than native vc++ compiler analyser). But remember 3DMagix and IllusionMage? Of course PVS-Studio is NOT a such scam, but only because Clang is under BSD license and not GPL. The problem is PVS-Studio have never returned a single line of code back to the Clang SVN. As for me I do not support such kind of business. 25 апреля 2012 г. 9:44 пользователь Campbell Barton ideasma...@gmail.com написал: for obvious things they mostly find the same issues (even same false positives), but each have a handful that are unique. I've ran blender through cppcheck, splint, sparse and clang-static-checler. the problem is that once you wade through the error logs (mainly false positives), and fixed the actual bugs... Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. On Wed, Apr 25, 2012 at 9:30 AM, Nicholas Bishop nicholasbis...@gmail.com wrote: Not necessarily; different static analyzers can detect different types of potential problems. The PVS analysis contains some interesting things like the Misprint in a homogeneous code block section that I don't think clang's analyzer does. On Tue, Apr 24, 2012 at 7:20 PM, Tom M letter...@gmail.com wrote: We have a page with generated CLang static analysis, http://clang.blenderheads.org/trunk/ It probably shows the same bugs as PVS-Studio does. LetterRip On Tue, Apr 24, 2012 at 4:15 PM, Nicholas Bishop nicholasbis...@gmail.com wrote: I think some of these have been fixed already in recent commits from Campbell. On Tue, Apr 24, 2012 at 7:11 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: http://www.viva64.com/en/b/0145/#ID0EO3BK It appears that Andrey Karpov has done an analysis of Blender source code using his PVS-Studio tool. He did this just yesterday, so I assume the problems he found are still in the source. He offers free licenses to open source project members (3500 euro software otherwise, wow). I was thinking of investigating the problems he found and seeing if I could fix them. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] trying to build with mingw32
Well I'll be darned! They did forget to include gcc...facepalm Yousef, can you try this installer instead? http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-2018/ ok, i downloaded and it compiles ok but not all! it seems it doesn't build OIIO? i get this error: scons: *** [Z:\Development\blender\install\win32-mingw\OpenImageIO.dll] Source ` Z:\Development\blender\lib\mingw32\openimageio\bin\OpenImageIO.dll' not found, n eeded by target `Z:\Development\blender\install\win32-mingw\OpenImageIO.dll'. i used the default config file. i checked the install folder and most thing are there and blender starts and doesn't crash and renders Regards Yousef Harfoush ba...@msn.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Quaternion interpolation is bumpy/wrong
What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The interpolation is not incorrect (insofar as interpolation can be incorrect). If you were doing linear, shortest-path interpolation, it _would_ be bending downward. Your main misunderstanding is that you are mistakenly thinking of the direction that the leg is pointing as the only relevant aspect of rotation. But that is not correct. The twist of the leg is also part of the rotation, and you are introducing a 90 degree twist with the second rotation. Take a look here: http://www.pasteall.org/blend/13542 I've added axis bones to make it more obvious what's going on. The setup on the left is your animation, and the setup on the right has been changed so that it's not twisting. Here's another file to take a look at: http://www.pasteall.org/blend/13543 It's the same as the one I linked above, except with linear interpolation (e.g. shortest path). It should be more visually obvious in this why you're getting the rotate down effect. --Nathan On Tue, Apr 24, 2012 at 3:12 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I don't know if this is a known issue. But i tried the following. I made a key for a leg (restpose), bended it forward (xrot 90°, second key) and moved it to the side (zrot 90°, third key), and then added a fourth key (restposition again). What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The reason for that is the interpolation (bezier curves) between the keys. It interpolates every component as a single key. But that isn't right for quaternion rotation. Instead it should interpolate between the quaternions (at the keys) itself using a slope function to define how the interpolation in between keyframes behaves. I uploaded an example to pasteall.org to illustrate the issue: http://www.pasteall.org/blend/13505 The left armature (named wrong) shows what i mean with wrong interpolation and the right armature shows how it should look like (named nearly right, because it is impossible to get it right at the moment). Maybe someone has the time to look at the example and to figure out a way how it could be correctly implemented. My attempt would be to remove the possibility to edit f-curves for quaternions (who does that anyway?) and to use another interpolation scheme for this kind of rotations. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Test account
It is really a good opportunity for buying electronic products. Don't miss it. Best regards! www.gmail123.com . △ ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Quaternion interpolation is bumpy/wrong
Yes, you're right. But I think that this is not really the kind of interpolation an animator would want to have in this case. As an animator I would prefer a direction interpolation and a separate roll interpolation. Ideally both rotations (as in your example files) would follow the same path on the rotation sphere, while only the roll behaves differently. Otherwise such movement will have this up/down curve, which isn't nice to look at. Greetings from Tobias Oelgarte Am 25.04.2012 22:21, schrieb Nathan Vegdahl: What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The interpolation is not incorrect (insofar as interpolation can be incorrect). If you were doing linear, shortest-path interpolation, it _would_ be bending downward. Your main misunderstanding is that you are mistakenly thinking of the direction that the leg is pointing as the only relevant aspect of rotation. But that is not correct. The twist of the leg is also part of the rotation, and you are introducing a 90 degree twist with the second rotation. Take a look here: http://www.pasteall.org/blend/13542 I've added axis bones to make it more obvious what's going on. The setup on the left is your animation, and the setup on the right has been changed so that it's not twisting. Here's another file to take a look at: http://www.pasteall.org/blend/13543 It's the same as the one I linked above, except with linear interpolation (e.g. shortest path). It should be more visually obvious in this why you're getting the rotate down effect. --Nathan On Tue, Apr 24, 2012 at 3:12 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I don't know if this is a known issue. But i tried the following. I made a key for a leg (restpose), bended it forward (xrot 90°, second key) and moved it to the side (zrot 90°, third key), and then added a fourth key (restposition again). What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The reason for that is the interpolation (bezier curves) between the keys. It interpolates every component as a single key. But that isn't right for quaternion rotation. Instead it should interpolate between the quaternions (at the keys) itself using a slope function to define how the interpolation in between keyframes behaves. I uploaded an example to pasteall.org to illustrate the issue: http://www.pasteall.org/blend/13505 The left armature (named wrong) shows what i mean with wrong interpolation and the right armature shows how it should look like (named nearly right, because it is impossible to get it right at the moment). Maybe someone has the time to look at the example and to figure out a way how it could be correctly implemented. My attempt would be to remove the possibility to edit f-curves for quaternions (who does that anyway?) and to use another interpolation scheme for this kind of rotations. Greetings from Tobias Oelgarte ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
If the source line changes then diff isn't a good enough tool. What is needed is a that these programs need to maintain a database that keeps a signature of each problem that is basically an AST of the area affected and is independent of source line and whitespace changes. Then you could annotate this database with information about false positives instead of your source. Such a database might even be able to keep new false positives from appearing if you duplicate the problem exactly in a different source file. On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen rus...@eecs.qmul.ac.uk wrote: Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
p.s., not that I'm against annotating false positives in source code (or better yet, rewriting in a less suspicious manner). I do not believe in forcing programmers to do things. However, if we ever wanted to require that Blender ship with zero warning flags from these kinds of tools there is going to have to be some kind of centralized way to customize the warnings so that all developers can work against the same template. This is why I like Sonar for Java, you can set up a central web server that tracks all the warnings and everybody can check against that. But it does not do exactly what I suggested (let you mark false-positives in the database). However, it is also a more sensible tool because I've never had it flag something I either did not really have to fix or was not actually a good suggestion to improve the code. C/C++ tools will probably never be that good. On top of that, I compiled Blender with MSVC 2008 warning level 4 and got 14,000 warnings. It would be nice to have a tool that could actually automatically track those. As it is, it seems like a nightmare to even try to see if there is anything useful in those 14k warnings. On Wed, Apr 25, 2012 at 5:57 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: If the source line changes then diff isn't a good enough tool. What is needed is a that these programs need to maintain a database that keeps a signature of each problem that is basically an AST of the area affected and is independent of source line and whitespace changes. Then you could annotate this database with information about false positives instead of your source. Such a database might even be able to keep new false positives from appearing if you duplicate the problem exactly in a different source file. On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen rus...@eecs.qmul.ac.uk wrote: Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Quaternion interpolation is bumpy/wrong
But I think that this is not really the kind of interpolation an animator would want to have in this case. As an animator I would prefer a direction interpolation and a separate roll interpolation. Believe me, as an animator and rigger, I have thought about this problem a lot. But it's not as simple as you make it out to be. Whenever you separate out axes of rotation like that, you introduce singularities. So you could, for example, use euler rotation with an appropriate rotation order to accomplish what you want here, but then it will interpolate strangely in other circumstances. For example, in this file: http://www.pasteall.org/blend/13547 From key-1 to key-2, and from key-2 to key-3, the interpolation behaves as you expect. But from key-3 to key-4 it behaves strangely. Even if we hide the interpolation curves entirely and let Blender do whatever strange things it wants to accomplish various interpolation methods internally, it's not clear to me that there's an obvious way to accomplish what you want in the general case, because roll is actually ill-defined for fully general 3d rotations. Besides which, if we do that, then we deprive animators of a lot of control via interpolation curves. You might be able to accomplish something close to what you want via some clever rigging, however, by having separate controls for the pointing direction and the roll. But you have to choose what pointing without rolling means then, which involves making some limiting assumptions. In any case, there is nothing broken about how Blender is interpolating your key frames. I agree it's crappy for this use-case, but I don't know of any existing methods that are less crappy. --Nathan On Wed, Apr 25, 2012 at 1:57 PM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: Yes, you're right. But I think that this is not really the kind of interpolation an animator would want to have in this case. As an animator I would prefer a direction interpolation and a separate roll interpolation. Ideally both rotations (as in your example files) would follow the same path on the rotation sphere, while only the roll behaves differently. Otherwise such movement will have this up/down curve, which isn't nice to look at. Greetings from Tobias Oelgarte Am 25.04.2012 22:21, schrieb Nathan Vegdahl: What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The interpolation is not incorrect (insofar as interpolation can be incorrect). If you were doing linear, shortest-path interpolation, it _would_ be bending downward. Your main misunderstanding is that you are mistakenly thinking of the direction that the leg is pointing as the only relevant aspect of rotation. But that is not correct. The twist of the leg is also part of the rotation, and you are introducing a 90 degree twist with the second rotation. Take a look here: http://www.pasteall.org/blend/13542 I've added axis bones to make it more obvious what's going on. The setup on the left is your animation, and the setup on the right has been changed so that it's not twisting. Here's another file to take a look at: http://www.pasteall.org/blend/13543 It's the same as the one I linked above, except with linear interpolation (e.g. shortest path). It should be more visually obvious in this why you're getting the rotate down effect. --Nathan On Tue, Apr 24, 2012 at 3:12 AM, Tobias Oelgarte tobias.oelga...@googlemail.com wrote: I don't know if this is a known issue. But i tried the following. I made a key for a leg (restpose), bended it forward (xrot 90°, second key) and moved it to the side (zrot 90°, third key), and then added a fourth key (restposition again). What i expected was a smooth motion, but instead it goes straight up (to 2nd key) and continues with a curve that _bends downward_ to key 3. Given that it has to move trough the keys i would have at least expected a linear motion (shortest path) from key 2 to key 3. The reason for that is the interpolation (bezier curves) between the keys. It interpolates every component as a single key. But that isn't right for quaternion rotation. Instead it should interpolate between the quaternions (at the keys) itself using a slope function to define how the interpolation in between keyframes behaves. I uploaded an example to pasteall.org to illustrate the issue: http://www.pasteall.org/blend/13505 The left armature (named wrong) shows what i mean with wrong interpolation and the right armature shows how it should look like (named nearly right, because it is impossible to get it right at the moment). Maybe someone has the time to look at the example and to figure out a way how it could be correctly implemented. My attempt would be to remove the
Re: [Bf-committers] Quaternion interpolation is bumpy/wrong
Rotations in 3D are just a horrible beast, and I think it is non trivial to figure out what constitutes a 'nice' interpolation across all cases, perhaps not even possible. You might be to use hierachies to isolate axis for some very specific setups, however: way how it could be correctly implemented. My attempt would be to remove the possibility to edit f-curves for quaternions (who does that anyway?) Lots and lots of animators edit quat f-curves- and wouldn't like 'taking the curve editor away' unless it is replaced with something better... (curve editor++ ? direct editing of paths/handles in the 3D view?) and to use another interpolation scheme for this kind of rotations. euler will have it's own, worse interpolation issues, but I'm not sure how axis angle would behave in this specific case. Does anyone actually use axis-angle and it's just me living in the stone age? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
While its probably possible to setup some `good enough` solution using diff, I tend to agree with Jason - that you need something more comprehensive so some minor edits to a file doesn't give you a lot of changes to the diff to read through that are in fact only line number change or re-ordered functions. Even though you could probably skim-read the diff and tell new additions from line-number offsets - blenders is changing fast enough that doing this every day would become a time waster IMHO. Another issue with diff, clang outputs HTML or PList (some apple xml?) - so diffing this output needs someone to work on a tool for that specifically. Checking if number of reports changed was OK until clang started crashing in some of our source code, so now it gives different bug count every run. http://clang.blenderheads.org/trunk/ (yes, I realize some bug could be added and another removed between revisions - so its not foolproof). On Thu, Apr 26, 2012 at 8:57 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: If the source line changes then diff isn't a good enough tool. What is needed is a that these programs need to maintain a database that keeps a signature of each problem that is basically an AST of the area affected and is independent of source line and whitespace changes. Then you could annotate this database with information about false positives instead of your source. Such a database might even be able to keep new false positives from appearing if you duplicate the problem exactly in a different source file. On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen rus...@eecs.qmul.ac.uk wrote: Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
On Thu, Apr 26, 2012 at 9:16 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: p.s., not that I'm against annotating false positives in source code (or better yet, rewriting in a less suspicious manner). I do not believe in forcing programmers to do things. However, if we ever wanted to require that Blender ship with zero warning flags from these kinds of tools there is going to have to be some kind of centralized way to customize the warnings so that all developers can work against the same template. This is why I like Sonar for Java, you can set up a central web server that tracks all the warnings and everybody can check against that. But it does not do exactly what I suggested (let you mark false-positives in the database). However, it is also a more sensible tool because I've never had it flag something I either did not really have to fix or was not actually a good suggestion to improve the code. C/C++ tools will probably never be that good. On top of that, I compiled Blender with MSVC 2008 warning level 4 and got 14,000 warnings. It would be nice to have a tool that could actually automatically track those. As it is, it seems like a nightmare to even try to see if there is anything useful in those 14k warnings. My first reaction when building blender in MSVC was - how can anyone use this! - the output flooded with warnings almost all being near useless, now IIRC the warning level is set lower now but its still not great. A while back I tried to get cmake/gcc building with zero warnings and we are close to being there (some are really hard to get rid of because of differences in external headers across versions). The way I did this was to set -Wall -Wextra, then disable warnings one by one which are things blender does often and are not useful to be warned about on every build. eg: -Wno-unknown-pragmas, -Wno-char-subscripts Another thing that was needed was a way to remove even more warnings for 3rd party libs in extern/ since we dont maintain that code making small edits only get lost when updating the libs. For this there is a CMake macro remove_strict_flags(), defined in ./build_files/cmake/macros.cmake to remove -Wunused-parameter, -Wstrict-prototypes for example. Locally I use -Werror so if someone commits error causing code into blender It won't build for me, but dont enable this by default since it would get annoying for non developers to build. Theres nothing stopping someone making use of this same methods for MSVC so we get useful warning output. 14,000 warnings sound bad but so many are harmless they just need to be suppressed. On Wed, Apr 25, 2012 at 5:57 PM, Jason Wilkins jason.a.wilk...@gmail.com wrote: If the source line changes then diff isn't a good enough tool. What is needed is a that these programs need to maintain a database that keeps a signature of each problem that is basically an AST of the area affected and is independent of source line and whitespace changes. Then you could annotate this database with information about false positives instead of your source. Such a database might even be able to keep new false positives from appearing if you duplicate the problem exactly in a different source file. On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen rus...@eecs.qmul.ac.uk wrote: Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] PVS-Studio Static Analysis
Interesting problem you have here. While I don't understand all the errors themselves per se, I did take a look at the root web page and a few samples of reports, along with a glimpse at the html it generated. My initial thought would be some sort of regex like parser that would be very similar in theory to the perl swatch script, or the logwatch. To summarize the aspects of these that would relate to this: swatch lets you setup regex rules to match or ignore entries in any text file, and can vary the color of the output, ignore it, or perform some action on a match. While logwatch is similar, it basically has a list of ignore rules/regex, and has formatting information for all the different syslog (and friends) log formats that it can parse out the junk (like timestamps and pid's). I figure that if someone felt like spending an evening, they could probably take the 2 key concepts (regex, and ignore rules per file and/or error) from these two programs and toss them into an html scraper script, you could probably get something that could alert you to just the stuff that has changed. For example, looking at a few different reports, I noticed a trend of the same file to have the same error on the same line number. Clearly in such a case, this output should be placed on the ignore list (well, assuming you choose to ignore it), and only report on changes where there is a new primary key of sorts, constructed from the uniqueness of the filename, error type and line number. The big problem I see with this, would be maintaining the script in the event that the html of the clang reports changes. This is actually the type of problem that I ran into when making the blender filesize chart, namely that over time, the conventions used to name files and indicate features was different per arch, release and feature set, thus making it near impossible to script or automate anything without hand verification. I suppose the question is, how important would something like this be, who will write it, how will it be written (perl+dbm, python+sqlite, etc etc etc), who will maintain it, who will use and benefit from it. Tbh, it sounds like a can of worms :) Anyways, felt like chiming in, later guys o/ troubled On Wed, Apr 25, 2012 at 9:36 PM, Campbell Barton ideasma...@gmail.com wrote: While its probably possible to setup some `good enough` solution using diff, I tend to agree with Jason - that you need something more comprehensive so some minor edits to a file doesn't give you a lot of changes to the diff to read through that are in fact only line number change or re-ordered functions. Even though you could probably skim-read the diff and tell new additions from line-number offsets - blenders is changing fast enough that doing this every day would become a time waster IMHO. Another issue with diff, clang outputs HTML or PList (some apple xml?) - so diffing this output needs someone to work on a tool for that specifically. Checking if number of reports changed was OK until clang started crashing in some of our source code, so now it gives different bug count every run. http://clang.blenderheads.org/trunk/ (yes, I realize some bug could be added and another removed between revisions - so its not foolproof). On Thu, Apr 26, 2012 at 8:57 AM, Jason Wilkins jason.a.wilk...@gmail.com wrote: If the source line changes then diff isn't a good enough tool. What is needed is a that these programs need to maintain a database that keeps a signature of each problem that is basically an AST of the area affected and is independent of source line and whitespace changes. Then you could annotate this database with information about false positives instead of your source. Such a database might even be able to keep new false positives from appearing if you duplicate the problem exactly in a different source file. On Wed, Apr 25, 2012 at 11:13 AM, Mr Rasmus Lerchedahl Petersen rus...@eecs.qmul.ac.uk wrote: Running a second time gives you only the false positives again. If some new bug is added to the source you still needed to read over the false positives (unless your memory is really good). long term we need to have a way to notify us when new errors are added. Sounds like a job for diff? ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Status of 2.63 release
Hi, what is the status now? According to sergey yesterday, we wait for a last minute bevel fix (patch was sent to Campbell to check) and the Splash. Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Status of 2.63 release
If I am not mistaken, I thought I seen a commit a few revisions ago today that specifically mentioned something about disabling bevel for release because of a discussion and/or problems. Not sure if that answers your question though. Ah yes, here it was: r45962 | campbellbarton | 2012-04-25 06:24:31 -0400 (Wed, 25 Apr 2012) | 2 lines disable bevel for release after discussion with brecht and sergey, this works far too poorly to be included in release. On Thu, Apr 26, 2012 at 12:05 AM, Thomas Dinges blen...@dingto.org wrote: Hi, what is the status now? According to sergey yesterday, we wait for a last minute bevel fix (patch was sent to Campbell to check) and the Splash. Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] OpenGL Dependency Report and Script
In preparation for SoC I have started to study how Blender uses OpenGL Here is a report I generated: http://www.pasteall.org/31251/ Here is the script I used to generate it: http://www.pasteall.org/31252/python You need to download a full glew to run it (and edit the file paths inside the script). I'm a novice python user, so please don't mind how primitive my code is ;) There are some obvious problems, the main one is that I assume each token belongs to exactly one opengl extension, which I do not think is true at all. The other is that some tokens inside Blender mimic OpenGL symbols. I think one of my first tasks will be to find those fake opengl symbols, like glMats, and rename them. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
