please rempve me from your mailing list ----- Original Message ----- From: <[email protected]> To: <[email protected]> Sent: Friday, November 12, 2010 4:00 AM Subject: Bf-committers Digest, Vol 76, Issue 21
> Send Bf-committers mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.blender.org/mailman/listinfo/bf-committers > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Bf-committers digest..." > > > Today's Topics: > > 1. Re: New blog: code.blender.org (proposal) (Thomas Dinges) > 2. Re: New blog: code.blender.org (proposal) (Thomas Dinges) > 3. Re: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [32998] > branches/particles-2010/source/ blender/nodes/intern: Replaced > the use of BLI random functions in the " Random" node by a > straightforward pseudo-random number generation based on > randomized arrays . (Kent Mein) > 4. Re: [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [32998] > branches/particles-2010/source/ blender/nodes/intern: Replaced > the use of BLI random functions in the " Random" node by a > straightforward pseudo-random number generation ba (Lukas T?nne) > 5. Re: Blender-2.55 has no menu bar (Dave Plater) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Nov 2010 14:36:58 +0100 > From: Thomas Dinges <[email protected]> > Subject: Re: [Bf-committers] New blog: code.blender.org (proposal) > To: bf-blender developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I also love the idea! > > For about 1 year I am thinking of creating my own blog to put some > information about the UI in there etc but never actually did it! :) > So i would use code.blender.org and I think it is a good idea! > > Thomas > > Am 11.11.2010 04:20, schrieb Dalai Felinto: >> I loved the idea. >> Not an aggregator but a coletive blog. >> >> I see myself using it to (1) help demonstrating new features (what we >> sometimes end up doing in the release log), (2) thinking out loud >> (sketching >> out ideas, sharing some thoughts on the future of some areas of >> BGE/Blender >> (3) replying to questions on how to use this of that feature (instead >> of >> doing that in emails / irc). >> It doesn't have to be structured and organized as wiki, so it can be >> pretty >> easy to add news there. >> >> Great idea Ton, >> Dalai > > > ------------------------------ > > Message: 2 > Date: Thu, 11 Nov 2010 14:39:10 +0100 > From: Thomas Dinges <[email protected]> > Subject: Re: [Bf-committers] New blog: code.blender.org (proposal) > To: bf-blender developers <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > +1 for this comment policy! > > Am 11.11.2010 10:43, schrieb mindrones: >> 2) Comments policy >> >> There are so many things to read that in the end you simply don't read >> anything anymore... >> >> Example: Durian posts --> if I see 175 comments I can expect 95% noise, >> like "cool!" comments, and "5%" interesting informations... >> >> There's the same risk here IMO, so I would like to propose that such a >> blog has a well stated COMMENTS POLICY (I took this idea from a cool >> javascript site I can't remember): >> >> - people freely comment and make questions >> >> - the blog author replies and when appropriate he enhances or fix the >> post above >> >> - the author deletes all noisy comments, so that the page is always good >> and complete, and we don't have to read noisy comments or things that >> have already been fixed in the post >> >> - to say "post has been cleaned up" the author just leaves a comment >> like "edited" or so, so we know, otherwise he just cleans noisy comments >> and don't leave a "edited" comment. >> >> - if he cleans many times, more of his "edited" stamps also let us know >> if/when it's worth re-reading the post >> >> IMO this would result in a beautiful workflow to do documentation: >> - wiki people can then use that material as a base for user docs >> - devs can use that as a base for dev documents too. >> >> >> Regards, >> Luca >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > ------------------------------ > > Message: 3 > Date: Thu, 11 Nov 2010 08:04:32 -0600 > From: Kent Mein <[email protected]> > Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: > /data/svn/bf-blender [32998] branches/particles-2010/source/ > blender/nodes/intern: Replaced the use of BLI random functions in the > " Random" node by a straightforward pseudo-random number generation > based on randomized arrays . > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On Nov 11, 2010, at 3:19 AM, Lukas Toenne wrote: > >> Revision: 32998 >> >> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=32998 >> Author: lukastoenne >> Date: 2010-11-11 10:19:06 +0100 (Thu, 11 Nov 2010) >> >> Log Message: >> ----------- >> Replaced the use of BLI random functions in the "Random" node by a >> straightforward pseudo-random number generation based on randomized >> arrays. This is a thread-safe implementation (the arrays are constant), >> the disadvantage is that the static arrays (one for ints, one for floats) >> are rather large (65536 entries) and still have a much shorter period >> than "real" RNGs. An alternative would be using a separate RNG for each >> thread, but that requires passing thread info to kernel functions. >> > > Wouldn't having different RNG's per thread be bad for animation? > You would get different results depending on the order of your "parts" > rendered. > > Kent > > > > ------------------------------ > > Message: 4 > Date: Thu, 11 Nov 2010 15:37:11 +0100 > From: Lukas T?nne <[email protected]> > Subject: Re: [Bf-committers] [Bf-blender-cvs] SVN commit: > /data/svn/bf-blender [32998] branches/particles-2010/source/ > blender/nodes/intern: Replaced the use of BLI random functions in the > " Random" node by a straightforward pseudo-random number generation ba > To: bf-blender developers <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > The RNG should be re-seeded for every generated random number anyway, > because in general you cannot rely on a fixed order of calls. This > seed is a combination (using a "double seed") of an element ID (so you > get different numbers for each work item) and a user-defined constant. > > However, the current method should work nicely for almost all cases. > It just uses a rather large (2^16) array of precalculated, constant > random numbers, so there is no risk of changing the result by > switching threads between the seeding and generation (race condition). > IIRC Jahka uses the same technique for particle randomization. > > On Thu, Nov 11, 2010 at 3:04 PM, Kent Mein <[email protected]> wrote: >> >> On Nov 11, 2010, at 3:19 AM, Lukas Toenne wrote: >> >>> Revision: 32998 >>> ? ? ? ? >>> ?http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=32998 >>> Author: ? lukastoenne >>> Date: ? ? 2010-11-11 10:19:06 +0100 (Thu, 11 Nov 2010) >>> >>> Log Message: >>> ----------- >>> Replaced the use of BLI random functions in the "Random" node by a >>> straightforward pseudo-random number generation based on randomized >>> arrays. This is a thread-safe implementation (the arrays are constant), >>> the disadvantage is that the static arrays (one for ints, one for >>> floats) are rather large (65536 entries) and still have a much shorter >>> period than "real" RNGs. An alternative would be using a separate RNG >>> for each thread, but that requires passing thread info to kernel >>> functions. >>> >> >> Wouldn't having different RNG's per thread be bad for animation? >> You would get different results depending on the order of your "parts" >> rendered. >> >> Kent >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > ------------------------------ > > Message: 5 > Date: Mon, 01 Nov 2010 21:01:51 +0200 > From: Dave Plater <[email protected]> > Subject: Re: [Bf-committers] Blender-2.55 has no menu bar > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/01/2010 01:52 AM, Campbell Barton wrote: >> You shouldn't need to copy files from /usr/share/blender into >> ~/.blender, if so then its a bug. >> > I understand from this that I can delete ~/.blender and blender will > create it on first use, is this correct? >> I just tested and it work as expected. >> >> With CMake, set the CMAKE_INSTALL_PREFIX variable, its "/usr/local" by >> default, I set it to "/opt/blender25" >> >> "make install" copies the files into the install prefix. >> > The make install part of using cmake over scons is a big step forward > from scons placing everything in install/linux2. I cannot use > %{buildroot}, which is where the files to populate the rpm go, in the > %build section of the spec file and scons didn't place the files in an > FHS type directory hierarchy. Now with make install I can use the > rpmbuild macro %makeinstall and the files go into FHS compliant > directories, I only have to move the locale directory to > /usr/share/locale. > My %{prefix} is /usr, %{_bindir}=/usr/bin and %{_datadir}=/usr/share. > >> For an example on using CMake to create a package see: >> ./build_files/package_spec/pacman/PKGBUILD >> >> You could look into why it cant find the script directory using strace. >> >> If you grep for the dir you filter out a lot of junk, notice the last >> line the path is found, eg: >> >> ~ # strace /opt/blender25/bin/blender 2>&1 | grep "/opt/blender25" >> execve("/opt/blender25/bin/blender", ["/opt/blender25/bin/blender"], >> [/* 36 vars */]) = 0 >> readlink("/proc/self/exe", "/opt/blender25/bin/blender", 4094) = 26 >> stat("/opt/blender25/bin/blender", {st_mode=S_IFREG|0755, >> st_size=125951465, ...}) = 0 >> stat("/opt/blender25/bin/2.55/config", 0x7fff8291a6e0) = -1 ENOENT (No >> such file or directory) >> stat("/opt/blender25/bin/2.55/config", 0x7fff8291a6a0) = -1 ENOENT (No >> such file or directory) >> stat("/opt/blender25/bin/2.55/python", 0x7fff8291a770) = -1 ENOENT (No >> such file or directory) >> stat("/opt/blender25/bin/release/python", 0x7fff8291a580) = -1 ENOENT >> (No such file or directory) >> stat("/opt/blender25/share/blender/2.55/python", 0x7fff8291a580) = -1 >> ENOENT (No such file or directory) >> readlink("/opt/blender25/bin/blender", 0x7fff82905940, 4096) = -1 >> EINVAL (Invalid argument) >> stat("/opt/blender25/bin/Modules/Setup", 0x7fff82906880) = -1 ENOENT >> (No such file or directory) >> stat("/opt/blender25/share/blender/2.55/scripts/modules", >> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 >> >> >> On Sun, Oct 31, 2010 at 10:56 PM, Dave Plater <[email protected]> >> wrote: >> >>> On 10/31/2010 08:29 PM, blendenzo wrote: >>> >>>> Oh, sorry. I guess this is related to ~/.blender, since the 2.54 and >>>> 2.55 folders do end up in ~/.blender. Would it be helpful for you to >>>> see a directory tree of my ~/.blender folder on Linux Mint? >>>> >>>> On 10/31/2010 02:25 PM, blendenzo wrote: >>>> >>>> >>>>> Hi Dave, >>>>> >>>>> I experienced a very similar error on Linux Mint, and it was not >>>>> related >>>>> to the ~/.blender folder. When the versioning changed from 2.54 to >>>>> 2.55, cmake was not properly updating the scripts folders. >>>>> Specifically, the folder /blender/2.54 should now be /blender/2.55, >>>>> since Blender is now looking for the UI scripts in the 2.55 folder. I >>>>> deleted the /blender/2.54 folder, but cmake did not replace it. In >>>>> the >>>>> end, I had to delete the entire build and build from scratch and this >>>>> solved the problem. >>>>> >>>>> Are you building fresh or building on top of a previous 2.54 build? >>>>> If >>>>> you are building on a previous build, I think this could be what is >>>>> causing the problem. >>>>> >>>>> Regards, >>>>> >>>>> Tony >>>>> >>>>> On 10/30/2010 09:56 AM, Dave Plater wrote: >>>>> >>>>> >>>>> >>>>>> Hi, I've opened Blender 2.5 Bug Tracker item #24454 for the lack of >>>>>> menu >>>>>> bar when I run blender. I built it with the following configuration : >>>>>> cmake ../ -DWITH_FFTW3:BOOL=on -DWITH_JACK:BOOL=on >>>>>> -DWITH_OPENCOLLADA:BOOL=on -DWITH_PLAYER:BOOL=off >>>>>> -DWITH_SNDFILE:BOOL=on -DOPENCOLLADA=/usr >>>>>> -DOPENCOLLADA_LIBPATH=/usr/lib64 -DOPENCOLLADA_INC=/usr/include >>>>>> -DWITH_PYTHON_INSTALL:BOOL=off -DWITH_PYTHON:BOOL=off >>>>>> -DWITH_IMAGE_OPENJPEG:BOOL=off -DWITH_FFMPEG:BOOL=off >>>>>> -DWITH_CXX_GUARDEDALLOC:BOOL=off >>>>>> '-DPYTHON_LIB=/usr/lib64}/libpython3.1.so' >>>>>> -DPYTHON_INC=/usr/include/python3.1 '-GUnix Makefiles' >>>>>> -DCMAKE_VERBOSE_MAKEFILE:BOOL=on >>>>>> -DCMAKE_INSTALL_PREFIX:PATH=/usr >>>>>> >>>>>> In the past this has been caused by the contents of ~/.blender but >>>>>> this >>>>>> time I've tried various things including using the .blender contents >>>>>> from : >>>>>> blender-2.54-beta-linux-glibc27-x86_64.tar.bz2 >>>>>> and I still have no menu bar. >>>>>> Can somebody please give me a clue where to look, especially what >>>>>> blender expects to find in .blender. >>>>>> Thanks >>>>>> Dave Plater >>>>>> _______________________________________________ >>>>>> >>>>>> >>> I've come to the conclusion that the /usr/share/blender/2.55 folder has >>> to be copied to ~/.blender but I've still got no menus. This is a clean >>> chrooted rpmbuild build and I've deleted and recreated .blender many >>> times. A view of your ~/.blender directory tree would be much >>> appreciated. >>> Regards >>> Dave P >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> >> >> >> > > > > ------------------------------ > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > > > End of Bf-committers Digest, Vol 76, Issue 21 > ********************************************* _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
