Re: [Bf-committers] r54932 build error [Modal (aka tripod) solver rework]
I believe the issue is now fixed in svn.
On Fri, Mar 1, 2013 at 12:11 PM, Sergey Sharybin sergey@gmail.comwrote:
Hrm, weird. Will look into it.
On Fri, Mar 1, 2013 at 7:10 AM, PerfectionCat
sindra1961reb...@yahoo.co.jp wrote:
Hi.
There is an error in the build.
extern\libmv\libmv\simple_pipeline\modal_solver.cc(59) : error C2719:
'marker': __declspec(align('16'))
Environment:
Windows XP/SP3 32bits
SCONS+msvc9
PerfectionCat.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
With best regards, Sergey Sharybin
--
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] help
Hi, Get an IRC chat client (lik XChat), and connect to server irc.freenode.net, and join channel #blendercoders For people new to our code you can get extensive support there. This mailinglist is not very efficient for such help. I would become too noisy for everyone too. -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands On 28 Feb, 2013, at 19:24, Jagrut Trivedi wrote: I got this error while automatic dependencies installation. Built target bf_python make[1]: *** [all] Error 2 make: *** [all] Error 2 I tried to install bf_python.but it also gives the error: Unable to locate package bf_python. ___ 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] Cannot the international font be removed from SVN?
Hi devs, Recently I submitted a patch and a bug related to the internationalization: [#34373] Use i18n monospace font in Text editor and Python console http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 [#34396] Some kanji characters in i18n font are unreadable for Japanese users http://projects.blender.org/tracker/index.php?func=detailaid=34396group_id=9atid=498 The patch [#34373] obviously needs additional international font for displaying CJK characters properly. Also, Japanese font is needed to solve the bug [#34396]. So, Blender have to use the following fonts at least: (1) proportional font (default) = bfont.ttf (2) monospace font (default) = bmonofont.ttf (3) proportional font (international) = droidsans.ttf (4) monospace font (international) (5) proportional font (Japanese) (6) monospace font (Japanese) I'm not sure if the other languages need additional fonts. If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. Thanks, -- IRIE Shinsuke ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cannot the international font be removed from SVN?
On Sat, Mar 2, 2013 at 12:50 AM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: Hi devs, Recently I submitted a patch and a bug related to the internationalization: [#34373] Use i18n monospace font in Text editor and Python console http://projects.blender.org/tracker/index.php?func=detailaid=34373group_id=9atid=127 [#34396] Some kanji characters in i18n font are unreadable for Japanese users http://projects.blender.org/tracker/index.php?func=detailaid=34396group_id=9atid=498 The patch [#34373] obviously needs additional international font for displaying CJK characters properly. Also, Japanese font is needed to solve the bug [#34396]. So, Blender have to use the following fonts at least: (1) proportional font (default) = bfont.ttf (2) monospace font (default) = bmonofont.ttf (3) proportional font (international) = droidsans.ttf (4) monospace font (international) (5) proportional font (Japanese) (6) monospace font (Japanese) I'm not sure if the other languages need additional fonts. If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. Thanks, -- IRIE Shinsuke As long as they are not loaded into memory when unused, I don't think its such a problem to distribute them with Blender. If Linux distros want to remove them from the packages we can make sure its possible to fonts on the system as a build option or just link the font to where blender expects it. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cannot the international font be removed from SVN?
On Fri, Mar 1, 2013 at 2:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. I think it would be good to use system fonts for the user interface, but that needs to be implemented for all operating systems then. Once that works, maybe we should still keep the font for render compatibility of text objects, or for users that prefer the UI to be exactly the same on different operating systems. I don't know how important those things are and I guess we can have that discussion, but we need people to actually implement system font support for Linux/BSD, Windows, Mac, Android, ... before we can actually consider removing the fonts. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cannot the international font be removed from SVN?
There was a patch for at least Alt Linux which uses fontconfig to select font from fonts installed to system. I don't consider it's fully finished because name of font is still hardcoded in that patch, but we'll need to make font name configurable or make it possible to choose it from list. On Fri, Mar 1, 2013 at 9:27 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: On Fri, Mar 1, 2013 at 2:50 PM, IRIE Shinsuke irieshins...@yahoo.co.jp wrote: If we solve these issues by adding the fonts (4)-(6) above, file sizes of the release archives increase by 5-10MB. Maybe Linux distro maintainers hate such bundled fonts because they must remove the fonts and apply some patches to build distro packages. I think the the international font should be removed and system-wide fonts should be used instead. I think it would be good to use system fonts for the user interface, but that needs to be implemented for all operating systems then. Once that works, maybe we should still keep the font for render compatibility of text objects, or for users that prefer the UI to be exactly the same on different operating systems. I don't know how important those things are and I guess we can have that discussion, but we need people to actually implement system font support for Linux/BSD, Windows, Mac, Android, ... before we can actually consider removing the fonts. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] security bug for blender mentioned in a security bulletin
Hey all there is a security notice/bug for blender, I don't recall seeing it mentioned here before so will pass it on... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5105 LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] security bug for blender mentioned in a security bulletin
Weird that was the link in the lwn.net notice, but it says it is blank, use this link instead... http://lwn.net/Articles/538440/ On Fri, Mar 1, 2013 at 10:42 AM, Tom M letter...@gmail.com wrote: Hey all there is a security notice/bug for blender, I don't recall seeing it mentioned here before so will pass it on... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5105 LetterRip ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] security bug for blender mentioned in a security bulletin
This links to a OpenSUSE bug where the status is RESOLVED/FIXED. In any case this issue has been discussed before here. On Fri, Mar 1, 2013 at 6:53 PM, Tom M letter...@gmail.com wrote: Weird that was the link in the lwn.net notice, but it says it is blank, use this link instead... http://lwn.net/Articles/538440/ On Fri, Mar 1, 2013 at 10:42 AM, Tom M letter...@gmail.com wrote: Hey all there is a security notice/bug for blender, I don't recall seeing it mentioned here before so will pass it on... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5105 LetterRip ___ 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] security bug for blender mentioned in a security bulletin
Wasn't this discussed like couple of times at least already? Discussed solution was to change default /tmp to, say ~/.cache/blender on linux and something the same for other platforms. But this doesn't gonna to work well because well, blender actually never delets this files and keeping them forever in a hidden folder in home.. Not actually something i would want to happen on my desktop. I think we could use mc-style temporary directories, which are /tmp/mc-$USER with 0700 file mode bits. Or maybe even include $PID to a path, so multiple instance of blender would not interfere when Save Buffers or FSA are enabled. On Sat, Mar 2, 2013 at 12:11 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: This links to a OpenSUSE bug where the status is RESOLVED/FIXED. In any case this issue has been discussed before here. On Fri, Mar 1, 2013 at 6:53 PM, Tom M letter...@gmail.com wrote: Weird that was the link in the lwn.net notice, but it says it is blank, use this link instead... http://lwn.net/Articles/538440/ On Fri, Mar 1, 2013 at 10:42 AM, Tom M letter...@gmail.com wrote: Hey all there is a security notice/bug for blender, I don't recall seeing it mentioned here before so will pass it on... http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-5105 LetterRip ___ 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 -- With best regards, Sergey Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Collecting fixes for 2.66a release.
Hi I went over commits since release and make a suggested list of changes to be included in 2.66a. There are some areas I'm unsure of: * Mougri's BGE animation fixes (mixed in a bit with refactoring). * Aligorith made some animation fixes after fairly large commits to animation code. * Sergof's Bullet/Physics are mixed with features and fixes. need feedback which are safe for release. * Cessen made changes/fixes to Rigify. == Revs Checked == Trunk: 54697 -- 54965 Ext: 4315 -- 4336 Arranged by name so authors can check on their own work since last release. == Trunk == dfelinto: 54733 54754 54912 moguri: 54738 54764 54767 54780 54837 nazgul: 54746 54748 54901 54934 54935 54946 54947 54960 blendix: 54760 54793 54868 54885 54942 54943 54944 54945 54959 54965 campbellbarton: 54776 54781 54783 54824 54833 54834 54835 54865 54866 54875 54877 54878 54879 54882 54883 54899 54900 54903 54907 54917 54920 54921 54923 54928 54929 psy-fi: 54788 ton: 54789 54790 54794 54816 54908 54910 54954 54961 nicholasbishop: 54827 gaiaclary: 54856 == Trunk (MAYBE) == dingto: 54948 aligorith: 54924 54926 54927 sergof: 54757 54799 54822 54855 54862 alexk: 54761 moguri: 54769 54772 gaiaclary: 54888 mont29: 54891 nazgul: 54904 54937 === Ext == campbellbarton: 4320 4325 4327 cessen: 4321 4334 4335 - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Modifier modularity/[plugability] - writefile
Hi Chad, just a note that these kinds of proposals for design changes
could be better collected on a wiki, where they can be updated/edited,
Then discussed here when we intend to implement them, Most of the
proposals we did for 2.5x were written up on wiki pages.
Eg:
http://wiki.blender.org/index.php/Dev:2.5/Source/Architecture/RNA
http://wiki.blender.org/index.php/Dev:2.5/Source/Python/API/Py3.1_Migration
more here...
http://wiki.blender.org/index.php/Dev:2.5/Source
On Thu, Feb 28, 2013 at 12:09 PM, Chad Fraleigh ch...@triularity.org wrote:
With the goal of blender [eventually/one day] having dynamically
loadable modifiers, there would be a long road of steps needed to get
there. Some of them, like making the modifier code base more modular,
appears to be relatively easy (moving the same code [for the most
part] around). Even without the loadable modifiers goal, doing this
seems worthy (less monolithic do-everythings-implementation code,
better cohesion). So with this sub-goal in mind, I would like to start
with relocating modifier-specific portions of the writefile.c code to
the module files themselves. Other cohesion areas would follow later.
The initial pass would involve mostly just moving the code from the
monolithic writefile.c to each module's .c file and have a call to the
modular function be left in it's place. A later phase would be to add
a 'writeData' hook to ModifierTypeInfo, and then it would be the same
as the other polymorphic modifier hooks. However in the first part the
new function wrappers are written in a generic/common way so switching
to ModifierTypeInfo hook form doesn't require any changes except maybe
making the function static (and even that is only because it no longer
has to be global).
In the example (see below), C++ style comments ('//') are used as
example notations and not literal would be comments in the code.
Another issue also dealt with (since fixing it lines up well with
the changes anyway).. Currently little (if any) of the writefile code
does/handles errors. So if there is an I/O error mid-way, or invalid
data structure detected while writing (e.g. a NULL field that should
_never_ be NULL), it just ignores the error and keeps on writing more
elements. This could easily lead to corrupted save files with no
feedback to the user that there was a problem. So in the new functions
a status code is always returned, which eventually the calling code
would check (and also return any errors upstream). In these examples I
use an 'int' status code (where 0 means error, and non-0 is success)
for a success boolean type value, but this could potentially use a
typedef-ed enum if more than just pass/fail is needed (but at the
price of a simple if(!x(...)) calling expression). Another fix
is using const for arguments that point to data that won't be altered
by the function (like [blo_]write_struct() in the example).
A while back I made sure saving files on a disk with not enough room
gave propper error messages to the user,
While the code could probably do more fine grained error checks, are
there some steps you found that cause a bug?
(if so tracker report would be good)
There are some local write_X() functions used in the existing
code. To minimize the risk of hypothetical side breakage I add a
public wrapper using the blo_ prefix (and including a status code
placeholder) for those that would need to be called from relocated
modifier code. Eventually once nothing references the legacy
function(s) directly, they would be merged with/changed to be the
public version (and ideally return a real status code, if available).
I also wasn't sure which case convention to use for function prefixes
(i.e. mod_ vs MOD_ or blo_ vs BLO_) as existing code doesn't always
use one form consistently.
I would be willing to do most of the conversion leg-work.. Move/update
the code from writefile to the appropriate modules, add the
[available] error checking, etc.. and submit the patch files. Then
someone with commit would simply have to look it over and commit it,
or reject it because I missed something in that conversion, or reject
it if the patch didn't apply cleanly (i.e. the svn code changed in
between). In the later case I would just create and submit a new patch
from the updated code (as not to waste the commiter's time with
[messy?] merge work). For each modifier conversion I would first send
out a message to bf-committers a day ahead with the planned files to
change, in case anyone has significant commits pending in those areas
(which another large change might interfere with), so they can veto
it. In situations like that I would just skip/delay that modifier and
go to another. After submitting the patch to the tracker, I would post
the reference to bf-committers for a commiter to [hopefully] handle
[more] quickly (and reduce the chance of a patch conflict). The other
option, if some commiter was willing, I could
