Re: [opensource-dev] TeamCity build production
OK, so I tracked down what's going on with the Mac builds, looks like we're tripping over an icky GCC 4.0 optimization bug which is "optimizing out" the NULL pointer checks in LLPipeline::compare_pools, probably inadvertently triggered by the changes for SNOW-643 (Water flickers and disappears in patches). More info and a temporary work-around at SNOW-761 I'd appreciate it if someone more familiar with the work from SNOW-643 could take a look at what may be causing it and a better solution. Aimee. On 22 Jul 2010, at 03:00, Philippe (Merov) Bossut wrote: > Hi, > > I went through the whole export and build system again on TeamCity and fixed > everything that was strictly build script and TeamCity config related. > Summary: > - viewer-public export: the export script was faulty, pointing to libs ad > artwork bundles that were empty since the swtich to TeamCity (7/12). This has > been fixed and exports since yesterday starting with build 207152 are > producing correct bundles. One note: the name of the bundle is a bit > confusing since it has "viewer-2-0" in it while the version is "2.1.0.x". > This is because the internal hg branch I'm using is named that way. This will > become "viewer-public" once we merge the export script there. > - Binary posting: the 1.x trunk (1.4) and 2.x trunk (2.1) were both dropped > in "viewer-source-downloads/2010/trunk" and could end up overwriting each > other. I fixed that by forcing the 1.x trunk in "2009" since it's what its > svn branch says. > - 1.4 Build posting: those were dropped in lala S3 land and unreachable > because of some svn client issue on TeamCity. Fixed. > - Email notification subject: I fixed the "Build ()" blank notification > subject to mention the branch and revision and added the "year" (2009/2010) > so we can easily spot the 1.x (2009) from the 2.x (2010) notifications > > We still have issues with the Mac executable produced, both for 1.x and 2.x > (different issues) but those are code (2.x) or build option (1.x) issues, not > TeamCity issues. > > I hope we'll seen a full "green" production cycle with downloadable and > usable binaries tomorrow. > > Thanks for your patience. > > - Merov > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [sldev-commits] Successful Build for ()
llcommon.dll is present in the current install of the LL build of 1.4 From: Nicky Perian To: Henri Beauchamp ; opensource-dev@lists.secondlife.com Sent: Mon, July 19, 2010 7:41:50 PM Subject: Re: [opensource-dev] [sldev-commits] Successful Build for () Posted to SNOW-713. From: Henri Beauchamp To: opensource-dev@lists.secondlife.com Sent: Mon, July 19, 2010 5:41:12 PM Subject: Re: [opensource-dev] [sldev-commits] Successful Build for () On Mon, 19 Jul 2010 13:23:48 -0700 (PDT), buildad...@lindenlab.com wrote: > CYGWIN: >http://secondlife.com/developers/opensource/downloads/2010///Snowglobe_1-4-0-0_Setup.exe >e > http://secondlife.com/developers/opensource/downloads/2010///good-build.CYGWIN Does anyone actually *try* the "successful builds" ?... This one misses llcomon.dll... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SL on ARM platform
Except there's many problems with the N900 that would have to be overcome. For starters its CPU clock is normally 200mhz below the minimum spec. Even though it can overclock you're going to be depending on pushing the CPU a lot more then what its suppose to operate at which will require additional cooling unless you want to shorten its lifespan. RAM is physically half of the minimum required. Yes you have 1 gig virtually using swap space, but swap is dependent on the memory card which will require a good memory card like a class 6 or better to avoid system lag due to heavy thrashing of swap space. Swap also naturally decreases the life of the memory card and such aggressive thrashing will speed that up. Finally SL is written to use OpenGL, not OpenGL ES which is a totally different beast. To successfully port SL to this device you would have to increase the efficiency of SL's code to run in a lower resource environment and adapt the rendering engine to use OpenGL ES instead otherwise you're looking at a client that would barely run if at all. Naali had the advantage of using a real game engine (ogre) and still being a young ground up project where very few things are set in stone with how it operates. If one has the time, the team, and the dedicated resources to tackle SL's shortcomings on that platform then by all means go for it and keep us updated. Personally though, I feel the Android platform with the newer phones coming out which have more CPU power and RAM would be a better choice to attempt a port (Google does have an NDK that you can use to code in C/C++). Ron Festa Virtual Worlds Admin Division of Continuing Studies at Rutgers University PGP key: http://bit.ly/b1ZyhY Phone: 732-474-8583 On Wed, Jul 21, 2010 at 8:01 PM, Tigro Spottystripes < tigrospottystri...@gmail.com> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > here is an excerpt from > https://secure.wikimedia.org/wikipedia/en/wiki/Nokia_N900 : > > "The Nokia N900 is powered by a high-end OMAP 3430 ARM Cortex A8 which > is a System-on-a-chip made by Texas Instruments based on a 65-nanometer > CMOS process. The OMAP 3430 is composed of three microprocessors; the > Cortex A8 running at 600 MHz used to run the OS and applications, the > PowerVR SGX 530 GPU made by Imagination Technologies which supports > OpenGL ES 2.0 and is capable of up to 14 MPolys/s and a TMS320C64x, the > digital signal processors, running at 430 MHz used to run the image > processing (camera), audio processing (telephony) and data transmission." > > I've read people managed to overclock the processor up to about 1 GHz, > some people even made it so the clock would change depending on how much > is being demanded from the processor, not only getting better > performance but also increased battery time. > > > On 20/7/2010 14:52, Altair Sythos Memo wrote: > > On Wed, 14 Jul 2010 12:35:01 + (GMT) > > DEEPAK JAIN wrote: > > > > compile on ARM is possible, depending on which operating system you > > want to do. ARM since V4 is basically a 32bit little endian processor > > (latest version big endian 64bit too), a GCC since V2.95 can compile > > ELF binaries. > > > > Using ARM linux you can follow a generic "standalone build" how-to > > (preconf libraries aren't compiled for ARM), but the problem is only > > shifted on performance side. I've worked on Familiar Project to > > 5years ago (ex-compaq linux project on ARM devices) and about all > > application written in a good ANSI C/C++ can be compiled without too > > much pain, the step after is who do all the rendering job. A lot of > > nowadays portable devices (handhelds, smartphone, pdaphone, tablet pc) > > have a "sort of" GPU or graphic co-processor, but very few of them have > > full OpenGL support (I think OpenGL2.1 is the minimum for latest > > viewers), some have only software OpenGL API (ridicolous performance). > > > > some detail more can be usefulkl to answer to your wuestion ;) > > ___ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/OpenSource-Dev > > Please read the policies before posting to keep unmoderated posting > privileges > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.14 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEAREKAAYFAkxHikAACgkQ8ZFfSrFHsmXY5QCeOx7nK9fi7kDXOx2GcSItiFAv > GVMAniN++5PN7mgnGDTLZxfbF6o+jrOg > =RN/k > -END PGP SIGNATURE- > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] jira patch name convention
+1 on this proposal. Using the JIRA number (as implied in the proposal) in the patch name is also very useful for folks like me who review a bunch of patches. I usually end up renaming the patch files when downloading them. Cheers, - Merov On Wed, Jul 21, 2010 at 6:49 AM, Aleric Inglewood < aleric.inglew...@gmail.com> wrote: > Hi all, > > the jira makes no difference between Snowglobe 1.4 and Snowglobe 2.1, the > two most active development branches > at the moment. While many jira entries are specifically about one or the > other, some things apply to both. > There are two ways to deal with this: either create a new jira for the same > thing, so we have two jira > entries about the same thing, one for patches related to 1.x and one for > patches related to 2.x. > However, that is not always feasible. The second option is to use one jira > for both and just attach > patches (if they differ) for both branches to the same jira. > > For that latter case I propose to use the following convention: > > Patches that are for 1.x should start with SNOW1-123_description.diff > Patches that are for 2.x should start with SNOW2-123_description.diff > > Leaving out the version would mean it applies in general. Ie, > SNOW-123_description.diff > should apply to 1.x and/or 2.x (depending on what the jira is about). > If there is a patch that is specifically for SG 2.0, and the patch for 2.1 > has to look different, you can call it SNOW20-123_description.diff, etc. > > Aleric > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
