From Lance.Corrimal at eregion.de Tue Aug 5 15:09:46 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 00:09:46 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? Message-ID: <70381876.R6EWcQncDB@kirika.eregion.home> Hi guys, i'm trying to find the spot in the source where the viewer creates a "can't rez object, parcel full" message, but for the life of me i cannot find it. Can someone point me at the right file? Cheers LC From darien.caldwell at gmail.com Tue Aug 5 16:11:11 2014 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Tue, 5 Aug 2014 16:11:11 -0700 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <70381876.R6EWcQncDB@kirika.eregion.home> References: <70381876.R6EWcQncDB@kirika.eregion.home> Message-ID: I'd suspect that the viewer simply makes a rez request to the Server, and the server makes the determination it can't be completed, and why. LIkely the server just sends back the error message via some sort of generic callback. In short the message wouldn't be in the viewer. I may be wrong though. - Dari On Tue, Aug 5, 2014 at 3:09 PM, Lance Corrimal wrote: > Hi guys, > > i'm trying to find the spot in the source where the viewer creates a "can't > rez object, parcel full" message, but for the life of me i cannot find it. > Can > someone point me at the right file? > > Cheers > LC > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140805/725294e9/attachment.htm From holydoughnuts at gmail.com Tue Aug 5 19:27:23 2014 From: holydoughnuts at gmail.com (holydoughnuts) Date: Tue, 05 Aug 2014 22:27:23 -0400 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <70381876.R6EWcQncDB@kirika.eregion.home> References: <70381876.R6EWcQncDB@kirika.eregion.home> Message-ID: <53E1928B.5010107@gmail.com> On 8/5/2014 6:09 PM, Lance Corrimal wrote: > Hi guys, > > i'm trying to find the spot in the source where the viewer creates a "can't > rez object, parcel full" message, but for the life of me i cannot find it. Can > someone point me at the right file? > > Cheers > LC It looks like this message an issue. 2014-08-06T02:23:55Z WARNING: LLTrans::findString: ONCE: Missing String in strings.xml: [Can't rez object '[zs] Mesh_Body ver2.0' at { 235.759, 217.87, 29.8414 } on parcel 'YYY' in region XXX because the parcel is too full.] From Lance.Corrimal at eregion.de Wed Aug 6 08:49:24 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 17:49:24 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: References: <70381876.R6EWcQncDB@kirika.eregion.home> Message-ID: <18523943.XfaxhYojV6@kumiko> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: > I'd suspect that the viewer simply makes a rez request to the Server, and > the server makes the determination it can't be completed, and why. LIkely > the server just sends back the error message via some sort of generic > callback. In short the message wouldn't be in the viewer. I may be wrong > though. That's exactly my problem here, I see a "missing string" error in my logfiles, but I can't find the missing string in the original strings.xml or notifications.xml of the development viewer... And I can't find the creation of the message itself, either, but in the original viewer i do get a "parcel full" error at the appropriate moment. I frankly do not know where to look 0.o Help! Cheers LC > > - Dari > > > On Tue, Aug 5, 2014 at 3:09 PM, Lance Corrimal > > wrote: > > Hi guys, > > > > i'm trying to find the spot in the source where the viewer creates a > > "can't > > rez object, parcel full" message, but for the life of me i cannot find it. > > Can > > someone point me at the right file? > > > > Cheers > > LC > > > > _______________________________________________ > > 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 From desmoulins.uchi at googlemail.com Wed Aug 6 09:51:47 2014 From: desmoulins.uchi at googlemail.com (Niran) Date: Wed, 6 Aug 2014 18:51:47 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <18523943.XfaxhYojV6@kumiko> References: <70381876.R6EWcQncDB@kirika.eregion.home> <18523943.XfaxhYojV6@kumiko> Message-ID: additionally i found this: fail Can't create object because \nthe parcel is full. This is the exact notification i get when i try to rez an object on a parcel that is full, the other one being the one i posted previously. Not sure about Viewer 1 but they seem to have different wording, you should still check out notifications.xml and strings.xml tho, also check your log file after it came up if the string for this notification is missing like for holydoughnuts, then you'll need to add it. Unable to create new object. The region is full. Found in skins/xui/en/default/notifications.xml Sorry me stupid i still havent figured out how this whole email opensource dev thing works, these are the last mails i send which seems like were send to the wrong people. 2014-08-06 17:49 GMT+02:00 Lance Corrimal : > Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: > > I'd suspect that the viewer simply makes a rez request to the Server, and > > the server makes the determination it can't be completed, and why. LIkely > > the server just sends back the error message via some sort of generic > > callback. In short the message wouldn't be in the viewer. I may be wrong > > though. > > > That's exactly my problem here, I see a "missing string" error in my > logfiles, > but I can't find the missing string in the original strings.xml or > notifications.xml of the development viewer... And I can't find the > creation > of the message itself, either, but in the original viewer i do get a > "parcel > full" error at the appropriate moment. > > I frankly do not know where to look 0.o > > Help! > > > Cheers > LC > > > > > > - Dari > > > > > > On Tue, Aug 5, 2014 at 3:09 PM, Lance Corrimal < > Lance.Corrimal at eregion.de> > > > > wrote: > > > Hi guys, > > > > > > i'm trying to find the spot in the source where the viewer creates a > > > "can't > > > rez object, parcel full" message, but for the life of me i cannot find > it. > > > Can > > > someone point me at the right file? > > > > > > Cheers > > > LC > > > > > > _______________________________________________ > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140806/bbad777f/attachment.htm From sldev at free.fr Wed Aug 6 11:38:48 2014 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 6 Aug 2014 20:38:48 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <18523943.XfaxhYojV6@kumiko> References: <70381876.R6EWcQncDB@kirika.eregion.home> <18523943.XfaxhYojV6@kumiko> Message-ID: <20140806203848.719e8b20.sldev@free.fr> On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote: > Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: > > I'd suspect that the viewer simply makes a rez request to the Server, and > > the server makes the determination it can't be completed, and why. LIkely > > the server just sends back the error message via some sort of generic > > callback. In short the message wouldn't be in the viewer. I may be wrong > > though. > > > That's exactly my problem here, I see a "missing string" error in my logfiles, > but I can't find the missing string in the original strings.xml or > notifications.xml of the development viewer... And I can't find the creation > of the message itself, either, but in the original viewer i do get a "parcel > full" error at the appropriate moment. > > I frankly do not know where to look 0.o > > Help! Look inside indra/newview/llviewermessage.cpp, process_alert_core() function. My *guess* (not having this problem, here, with v1-style notifications), is that you reach one of the std::string new_msg = LLNotifications::instance().getGlobalString(message); lines in that function, and there's no corresponding "global string" for that particular message, so the translation fails... Which is not surprising, because many server-side initiated messages don't have a template in notifications.xml neither any translation string in strings.xml. The v1 viewers were not attempting to translate such messages at all cost, so they just display them in plain English and without error. I suppose you could add a method in LLTrans that would allow you to check for the existence of a given string before actually calling LLTrans::findString (which errors out when the translation does not exist). If the translation doesn't exist, then just display the message "as is". To confirm my diagnosis, just put a few llinfos in process_alert_core() and see what happens... Henri. From Lance.Corrimal at eregion.de Wed Aug 6 12:13:18 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 21:13:18 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <20140806203848.719e8b20.sldev@free.fr> References: <70381876.R6EWcQncDB@kirika.eregion.home> <18523943.XfaxhYojV6@kumiko> <20140806203848.719e8b20.sldev@free.fr> Message-ID: <53E27E4E.80407@eregion.de> Hi, the part that I really don't get is where I see that that part of the code has not been changed in my viewer (comparing with viewer-release) but still behaves so differently... Cheers LC Am 06.08.2014 um 20:38 schrieb Henri Beauchamp: > On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote: > >> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: >>> I'd suspect that the viewer simply makes a rez request to the Server, and >>> the server makes the determination it can't be completed, and why. LIkely >>> the server just sends back the error message via some sort of generic >>> callback. In short the message wouldn't be in the viewer. I may be wrong >>> though. >> >> That's exactly my problem here, I see a "missing string" error in my logfiles, >> but I can't find the missing string in the original strings.xml or >> notifications.xml of the development viewer... And I can't find the creation >> of the message itself, either, but in the original viewer i do get a "parcel >> full" error at the appropriate moment. >> >> I frankly do not know where to look 0.o >> >> Help! > Look inside indra/newview/llviewermessage.cpp, process_alert_core() function. > My *guess* (not having this problem, here, with v1-style notifications), is > that you reach one of the > std::string new_msg = LLNotifications::instance().getGlobalString(message); > lines in that function, and there's no corresponding "global string" for > that particular message, so the translation fails... Which is not surprising, > because many server-side initiated messages don't have a template in > notifications.xml neither any translation string in strings.xml. > > The v1 viewers were not attempting to translate such messages at all cost, > so they just display them in plain English and without error. > > I suppose you could add a method in LLTrans that would allow you to check > for the existence of a given string before actually calling > LLTrans::findString (which errors out when the translation does not > exist). If the translation doesn't exist, then just display the message > "as is". > > To confirm my diagnosis, just put a few llinfos in process_alert_core() and > see what happens... > > Henri. > From Lance.Corrimal at eregion.de Wed Aug 6 12:45:52 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 21:45:52 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <53E27E4E.80407@eregion.de> References: <70381876.R6EWcQncDB@kirika.eregion.home> <20140806203848.719e8b20.sldev@free.fr> <53E27E4E.80407@eregion.de> Message-ID: <2616854.d3gLrcXq5P@kumiko> Well i'll be damned. Would any of you believe that this change fixed this problem? http://dolphinsource.eregion.de/dolphinviewer3-beta/commits/9d50f4af1158b49364cfb0d38090c7947db56f03 *facepalm* How is one supposed to apply logic to stuff like that. Cheers LC Am Mittwoch, 6. August 2014, 21:13:18 schrieb Lance Corrimal: > Hi, > > > the part that I really don't get is where I see that that part of the > code has not been changed in my viewer (comparing with viewer-release) > but still behaves so differently... > > Cheers > LC > > Am 06.08.2014 um 20:38 schrieb Henri Beauchamp: > > On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote: > >> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: > >>> I'd suspect that the viewer simply makes a rez request to the Server, > >>> and > >>> the server makes the determination it can't be completed, and why. > >>> LIkely > >>> the server just sends back the error message via some sort of generic > >>> callback. In short the message wouldn't be in the viewer. I may be wrong > >>> though. > >> > >> That's exactly my problem here, I see a "missing string" error in my > >> logfiles, but I can't find the missing string in the original > >> strings.xml or notifications.xml of the development viewer... And I > >> can't find the creation of the message itself, either, but in the > >> original viewer i do get a "parcel full" error at the appropriate > >> moment. > >> > >> I frankly do not know where to look 0.o > >> > >> Help! > > > > Look inside indra/newview/llviewermessage.cpp, process_alert_core() > > function. My *guess* (not having this problem, here, with v1-style > > notifications), is that you reach one of the > > std::string new_msg = > > LLNotifications::instance().getGlobalString(message); > > lines in that function, and there's no corresponding "global string" for > > that particular message, so the translation fails... Which is not > > surprising, because many server-side initiated messages don't have a > > template in notifications.xml neither any translation string in > > strings.xml. > > > > The v1 viewers were not attempting to translate such messages at all cost, > > so they just display them in plain English and without error. > > > > I suppose you could add a method in LLTrans that would allow you to check > > for the existence of a given string before actually calling > > LLTrans::findString (which errors out when the translation does not > > exist). If the translation doesn't exist, then just display the message > > "as is". > > > > To confirm my diagnosis, just put a few llinfos in process_alert_core() > > and > > see what happens... > > > > 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 From Lance.Corrimal at eregion.de Wed Aug 6 12:51:44 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 21:51:44 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <2616854.d3gLrcXq5P@kumiko> References: <70381876.R6EWcQncDB@kirika.eregion.home> <53E27E4E.80407@eregion.de> <2616854.d3gLrcXq5P@kumiko> Message-ID: <1677249.IZoNVs4KLP@kumiko> Am Mittwoch, 6. August 2014, 21:45:52 schrieb Lance Corrimal: > Well i'll be damned. > > Would any of you believe that this change fixed this problem? > http://dolphinsource.eregion.de/dolphinviewer3-beta/commits/9d50f4af1158b493 > 64cfb0d38090c7947db56f03 > > *facepalm* > > How is one supposed to apply logic to stuff like that. ...and even more fun: now it also works in my previous builds that do not have that "fix". *doublefacepalm* > > > Cheers > LC > > Am Mittwoch, 6. August 2014, 21:13:18 schrieb Lance Corrimal: > > Hi, > > > > > > the part that I really don't get is where I see that that part of the > > code has not been changed in my viewer (comparing with viewer-release) > > but still behaves so differently... > > > > Cheers > > LC > > > > Am 06.08.2014 um 20:38 schrieb Henri Beauchamp: > > > On Wed, 06 Aug 2014 17:49:24 +0200, Lance Corrimal wrote: > > >> Am Dienstag, 5. August 2014, 16:11:11 schrieb Darien Caldwell: > > >>> I'd suspect that the viewer simply makes a rez request to the Server, > > >>> and > > >>> the server makes the determination it can't be completed, and why. > > >>> LIkely > > >>> the server just sends back the error message via some sort of generic > > >>> callback. In short the message wouldn't be in the viewer. I may be > > >>> wrong > > >>> though. > > >> > > >> That's exactly my problem here, I see a "missing string" error in my > > >> logfiles, but I can't find the missing string in the original > > >> strings.xml or notifications.xml of the development viewer... And I > > >> can't find the creation of the message itself, either, but in the > > >> original viewer i do get a "parcel full" error at the appropriate > > >> moment. > > >> > > >> I frankly do not know where to look 0.o > > >> > > >> Help! > > > > > > Look inside indra/newview/llviewermessage.cpp, process_alert_core() > > > function. My *guess* (not having this problem, here, with v1-style > > > notifications), is that you reach one of the > > > std::string new_msg = > > > LLNotifications::instance().getGlobalString(message); > > > lines in that function, and there's no corresponding "global string" for > > > that particular message, so the translation fails... Which is not > > > surprising, because many server-side initiated messages don't have a > > > template in notifications.xml neither any translation string in > > > strings.xml. > > > > > > The v1 viewers were not attempting to translate such messages at all > > > cost, > > > so they just display them in plain English and without error. > > > > > > I suppose you could add a method in LLTrans that would allow you to > > > check > > > for the existence of a given string before actually calling > > > LLTrans::findString (which errors out when the translation does not > > > exist). If the translation doesn't exist, then just display the message > > > "as is". > > > > > > To confirm my diagnosis, just put a few llinfos in process_alert_core() > > > and > > > see what happens... > > > > > > 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 From sldev at free.fr Wed Aug 6 14:27:58 2014 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 6 Aug 2014 23:27:58 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <1677249.IZoNVs4KLP@kumiko> References: <70381876.R6EWcQncDB@kirika.eregion.home> <53E27E4E.80407@eregion.de> <2616854.d3gLrcXq5P@kumiko> <1677249.IZoNVs4KLP@kumiko> Message-ID: <20140806232758.1f9df52d.sldev@free.fr> On Wed, 06 Aug 2014 21:51:44 +0200, Lance Corrimal wrote: > > Would any of you believe that this change fixed this problem? > > http://dolphinsource.eregion.de/dolphinviewer3-beta/commits/9d50f4af1158b493 > > 64cfb0d38090c7947db56f03 > > > > *facepalm* > > > > How is one supposed to apply logic to stuff like that. > > ...and even more fun: now it also works in my previous builds that do not have > that "fix". > > *doublefacepalm* No surprise... "that fix" is not a fix, it's just an indenting change. The good news is that C++ is not Python, and indenting doesn't make a difference in C++. You probably changed something else in the non-working build, which broke the process_alert_core() function... Henri. From Lance.Corrimal at eregion.de Wed Aug 6 14:33:13 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 06 Aug 2014 23:33:13 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <20140806232758.1f9df52d.sldev@free.fr> References: <70381876.R6EWcQncDB@kirika.eregion.home> <1677249.IZoNVs4KLP@kumiko> <20140806232758.1f9df52d.sldev@free.fr> Message-ID: <1571216.kHLgy6IOQP@kumiko> Am Mittwoch, 6. August 2014, 23:27:58 schrieb Henri Beauchamp: > You probably changed something else in the non-working build, which > broke the process_alert_core() function... Nope, nothing. I'm thinking that the "parcel full" message gone missing was one of the many effects of a ban list not loaded... Seeing how even the previous build which yesterday still had the parcel full message missing in action now behaves properly. Cheers LC From nickyperian at yahoo.com Wed Aug 6 15:04:54 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Wed, 6 Aug 2014 15:04:54 -0700 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <1571216.kHLgy6IOQP@kumiko> References: <70381876.R6EWcQncDB@kirika.eregion.home> <1677249.IZoNVs4KLP@kumiko> <20140806232758.1f9df52d.sldev@free.fr> <1571216.kHLgy6IOQP@kumiko> Message-ID: <1407362694.40244.YahooMailNeo@web163206.mail.gq1.yahoo.com> Lance, Do you think it could be a server version problem? Not working then works on a different logon region. Or was corrected with today's server deploys. Nicky >________________________________ > From: Lance Corrimal >To: opensource-dev at lists.secondlife.com >Sent: Wednesday, August 6, 2014 4:33 PM >Subject: Re: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? > > >Am Mittwoch, 6. August 2014, 23:27:58 schrieb Henri Beauchamp: > >> You probably changed something else in the non-working build, which >> broke the process_alert_core() function... > > >Nope, nothing. I'm thinking that the "parcel full" message gone missing was >one of the many effects of a ban list not loaded... Seeing how even the >previous build which yesterday still had the parcel full message missing in >action now behaves properly. > > >Cheers >LC > > > > >_______________________________________________ >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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140806/c705ae5f/attachment-0001.htm From monty at lindenlab.com Wed Aug 6 22:51:58 2014 From: monty at lindenlab.com (Monty Brandenberg) Date: Thu, 07 Aug 2014 01:51:58 -0400 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <53C5B6A8.5090206@lindenlab.com> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> <20140715200121.c81ba742.sldev@free.fr> <53C5719C.9090605@lindenlab.com> <20140716000100.0a553bf9.sldev@free.fr> <53C5B6A8.5090206@lindenlab.com> Message-ID: <53E313FE.90503@lindenlab.com> Checking in to see if anyone is seeing problems with the new libraries. Crash reports have been mostly quiet and as expected. No lurking horrors yet? m From Lance.Corrimal at eregion.de Thu Aug 7 00:07:24 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 07 Aug 2014 09:07:24 +0200 Subject: [opensource-dev] someone get the blindfold off me please - where in the sourcecode is the spot where a "parcel full" message is created? In-Reply-To: <1407362694.40244.YahooMailNeo@web163206.mail.gq1.yahoo.com> References: <70381876.R6EWcQncDB@kirika.eregion.home> <1571216.kHLgy6IOQP@kumiko> <1407362694.40244.YahooMailNeo@web163206.mail.gq1.yahoo.com> Message-ID: <2106347.TQyzZfAfk1@kumiko> Am Mittwoch, 6. August 2014, 15:04:54 schrieb Nicky Perian: > Lance, > Do you think it could be a server version problem? Not working then works on > a different logon region. Or was corrected with today's server deploys. > Nicky Could be that, too... I did my tests in the same region all the time tho, so the weekly deploys could have been the only thing. Anyway back do coding. Cheers LC > > >________________________________ > > > > From: Lance Corrimal > > > >To: opensource-dev at lists.secondlife.com > >Sent: Wednesday, August 6, 2014 4:33 PM > >Subject: Re: [opensource-dev] someone get the blindfold off me please > >- where in the sourcecode is the spot where a "parcel full" message is > >created?> > >Am Mittwoch, 6. August 2014, 23:27:58 schrieb Henri Beauchamp: > >> You probably changed something else in the non-working build, which > >> broke the process_alert_core() function... > > > >Nope, nothing. I'm thinking that the "parcel full" message gone missing was > >one of the many effects of a ban list not loaded... Seeing how even the > >previous build which yesterday still had the parcel full message missing in > >action now behaves properly. > > > > > >Cheers > >LC > > > > > > > > > >_______________________________________________ > >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 From sldev at free.fr Thu Aug 7 11:08:50 2014 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 7 Aug 2014 20:08:50 +0200 Subject: [opensource-dev] Library Refresh viewer In-Reply-To: <53E313FE.90503@lindenlab.com> References: <53BEC75F.3090803@lindenlab.com> <20140715165927.a70155d5.sldev@free.fr> <53C5652A.4080207@lindenlab.com> <20140715200121.c81ba742.sldev@free.fr> <53C5719C.9090605@lindenlab.com> <20140716000100.0a553bf9.sldev@free.fr> <53C5B6A8.5090206@lindenlab.com> <53E313FE.90503@lindenlab.com> Message-ID: <20140807200850.654c668c.sldev@free.fr> On Thu, 07 Aug 2014 01:51:58 -0400, Monty Brandenberg wrote: > Checking in to see if anyone is seeing problems with the new > libraries. Crash reports have been mostly quiet and as > expected. No lurking horrors yet? No problem whatsoever here: running the new library set under Linux with the Cool VL Viewer for almost 4 weeks already, and Cool VL Viewer users running the same set under both Linux and Windows for almost three weeks... No bug report so far. Henri. From nickyperian at yahoo.com Tue Aug 12 16:26:12 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 12 Aug 2014 16:26:12 -0700 Subject: [opensource-dev] library refresh viewer Message-ID: <1407885972.27523.YahooMailNeo@web163206.mail.gq1.yahoo.com> 1. boost-- Is the openssl that is populated in 3p-boost-update the same version as the one used by the viewer? I'm thinking it comes from boost. 2. Kokua is built with gcc-4.7. linux 32 Slplugin.exe would not link with boost built with gcc-4.6. Built boost with gcc-4.7 and there was no longer a link issue. But, stock SL viewer will not build on gcc-4.7 anyway so, it will be sometime before LL sees that issue. 3. For TPV dev's using gcc-4.7 Kokua's archive for linux 32 bit boost (gcc-4.7) is at: https://bitbucket.org/kokua/3p-boost-update/downloads Nicky -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140812/b7a496a2/attachment.htm From monty at lindenlab.com Wed Aug 13 10:37:18 2014 From: monty at lindenlab.com (Monty Brandenberg) Date: Wed, 13 Aug 2014 13:37:18 -0400 Subject: [opensource-dev] library refresh viewer In-Reply-To: <1407885972.27523.YahooMailNeo@web163206.mail.gq1.yahoo.com> References: <1407885972.27523.YahooMailNeo@web163206.mail.gq1.yahoo.com> Message-ID: <53EBA24E.4080204@lindenlab.com> On 8/12/2014 7:26 PM, Nicky Perian wrote: > 1. boost-- > Is the openssl that is populated in 3p-boost-update the same version as > the one used by the viewer? > I'm thinking it comes from boost. No openssl distributed by Boost, just the asio library using it and SL shouldn't be using asio. Asio also doesn't build any binary artifacts, other than test cases, so no symbol dependencies. When used, it will pick up whatever version is found in the build environment. -- Monty Brandenberg | Unit of Production Skype monty.linden | Second Life Monty Linden Linden Lab | Makers of Shared Creative Spaces Check out what we're working on! From nickyperian at yahoo.com Wed Aug 13 11:32:04 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Wed, 13 Aug 2014 11:32:04 -0700 Subject: [opensource-dev] library refresh viewer In-Reply-To: <53EBA24E.4080204@lindenlab.com> References: <1407885972.27523.YahooMailNeo@web163206.mail.gq1.yahoo.com> <53EBA24E.4080204@lindenlab.com> Message-ID: <1407954724.37449.YahooMailNeo@web163205.mail.gq1.yahoo.com> Dumbness on my part, it was a package of the 1.52 boost to build 64 bit version. It is headers only so likely not even required. On Wednesday, August 13, 2014 12:37 PM, Monty Brandenberg wrote: > > >On 8/12/2014 7:26 PM, Nicky Perian wrote: > >> 1. boost-- >> Is the openssl that is populated in 3p-boost-update the same version as >> the one used by the viewer? >> I'm thinking it comes from boost. > >No openssl distributed by Boost, just the asio library using it >and SL shouldn't be using asio.? Asio also doesn't build any >binary artifacts, other than test cases, so no symbol dependencies. >When used, it will pick up whatever version is found in the build >environment. > >-- >Monty Brandenberg | Unit of Production >Skype monty.linden | Second Life Monty Linden > >Linden Lab | Makers of Shared Creative Spaces >Check out what we're working on! >_______________________________________________ >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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140813/c502cfc2/attachment.htm From sldev at free.fr Thu Aug 14 07:37:21 2014 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 14 Aug 2014 16:37:21 +0200 Subject: [opensource-dev] Telehubs Message-ID: <20140814163721.a062f535.sldev@free.fr> Greetings, During my never-ending viewer code cleanup efforts, I came accross an old floater, the "Telehub" one... If I am correct, I think this dates back from the most ancient times of SL, when it was not possible to TP all over the grid, but only to some pre-defined hubs... Fact is, since my fist day in SL, back in 2006, I never came accross one such thing as a telehub on the grid ! I checked, and that code is still in the newest v3 viewer branches. So my question is: is there any practical usage any more for that "Telehub" floater ? And as a corollary question: are Telehubs in use (or even implemented at all) in OpenSim ? Henri. From kirstiemc555 at hotmail.co.uk Thu Aug 14 08:02:14 2014 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Thu, 14 Aug 2014 16:02:14 +0100 Subject: [opensource-dev] Telehubs In-Reply-To: <20140814163721.a062f535.sldev@free.fr> References: <20140814163721.a062f535.sldev@free.fr> Message-ID: I wouldn't remove that floater. Telehubs are still used in some places. Couple of quick examples: https://jira.secondlife.com/browse/BUG-5331https://jira.secondlife.com/browse/BUG-6678 Whirly Fizzle > Date: Thu, 14 Aug 2014 16:37:21 +0200 > From: sldev at free.fr > To: opensource-dev at lists.secondlife.com > Subject: [opensource-dev] Telehubs > > Greetings, > > During my never-ending viewer code cleanup efforts, I came accross an > old floater, the "Telehub" one... If I am correct, I think this dates > back from the most ancient times of SL, when it was not possible to TP > all over the grid, but only to some pre-defined hubs... Fact is, since > my fist day in SL, back in 2006, I never came accross one such thing > as a telehub on the grid ! > > I checked, and that code is still in the newest v3 viewer branches. > > So my question is: is there any practical usage any more for that > "Telehub" floater ? > > And as a corollary question: are Telehubs in use (or even implemented > at all) in OpenSim ? > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140814/15c385d7/attachment.htm From soft at lindenlab.com Thu Aug 14 08:02:01 2014 From: soft at lindenlab.com (Brian McGroarty) Date: Thu, 14 Aug 2014 08:02:01 -0700 Subject: [opensource-dev] Telehubs In-Reply-To: <20140814163721.a062f535.sldev@free.fr> References: <20140814163721.a062f535.sldev@free.fr> Message-ID: On Thu, Aug 14, 2014 at 7:37 AM, Henri Beauchamp wrote: > Greetings, > > During my never-ending viewer code cleanup efforts, I came accross an > old floater, the "Telehub" one... If I am correct, I think this dates > back from the most ancient times of SL, when it was not possible to TP > all over the grid, but only to some pre-defined hubs... Fact is, since > my fist day in SL, back in 2006, I never came accross one such thing > as a telehub on the grid ! > > I checked, and that code is still in the newest v3 viewer branches. > > So my question is: is there any practical usage any more for that > "Telehub" floater ? > Telehubs are available to privately owned estates. I don't know how common usage actually is, but they offer some unique features that aren't available with parcel landing points. These allow estate owners to: * configure multiple spawn points so agents are distributed to multiple specific locations within a region regardless of the attempted TP location * set spawn points on a build and then move the build with ingress points still intact (internally, the sim references target prims rather than locations - it should even be possible to move an object with scripts to prevent pileups, although I don't know if that's been tested) * route teleports to a single region for teleport attempts into any other region that's in the same estate, and where the alternate region isn't configured to allow direct teleport -- *Brian McGroarty *| Application Security, Platform Engineering *Linden Lab* | Makers of Shared Creative Spaces -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140814/990e9c44/attachment.htm From marinekelley at gmail.com Thu Aug 14 10:00:01 2014 From: marinekelley at gmail.com (Marine Kelley) Date: Thu, 14 Aug 2014 19:00:01 +0200 Subject: [opensource-dev] Near clip plane for impostors Message-ID: Hello all, Does anyone know how I can control the value of the near clip plane for the rendering of impostors please ? I've noticed that the camera will clip them from 1m away, leaving holes in it, but sometimes the camera is restricted to even closer than that, so I need to be able to render them fully even from up close. Thanks, Marine -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140814/1994b609/attachment.htm From darien.caldwell at gmail.com Thu Aug 14 10:11:18 2014 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu, 14 Aug 2014 10:11:18 -0700 Subject: [opensource-dev] Telehubs In-Reply-To: References: <20140814163721.a062f535.sldev@free.fr> Message-ID: Yep, Telehubs are still an active feature. I used them on my estate to manage traffic ( you can set them up to select arrival points in a round-robin style, so not everyone piles on top of each other). On Thu, Aug 14, 2014 at 8:02 AM, Brian McGroarty wrote: > On Thu, Aug 14, 2014 at 7:37 AM, Henri Beauchamp wrote: > >> Greetings, >> >> During my never-ending viewer code cleanup efforts, I came accross an >> old floater, the "Telehub" one... If I am correct, I think this dates >> back from the most ancient times of SL, when it was not possible to TP >> all over the grid, but only to some pre-defined hubs... Fact is, since >> my fist day in SL, back in 2006, I never came accross one such thing >> as a telehub on the grid ! >> >> I checked, and that code is still in the newest v3 viewer branches. >> >> So my question is: is there any practical usage any more for that >> "Telehub" floater ? >> > > Telehubs are available to privately owned estates. I don't know how common > usage actually is, but they offer some unique features that aren't > available with parcel landing points. > > These allow estate owners to: > > * configure multiple spawn points so agents are distributed to multiple > specific locations within a region regardless of the attempted TP location > * set spawn points on a build and then move the build with ingress points > still intact (internally, the sim references target prims rather than > locations - it should even be possible to move an object with scripts to > prevent pileups, although I don't know if that's been tested) > * route teleports to a single region for teleport attempts into any other > region that's in the same estate, and where the alternate region isn't > configured to allow direct teleport > > > -- > *Brian McGroarty *| Application Security, Platform Engineering > > *Linden Lab* | Makers of Shared Creative Spaces > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140814/c5cde144/attachment.htm From sldev at free.fr Thu Aug 14 10:28:07 2014 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 14 Aug 2014 19:28:07 +0200 Subject: [opensource-dev] Telehubs In-Reply-To: References: <20140814163721.a062f535.sldev@free.fr> Message-ID: <20140814192807.749052d8.sldev@free.fr> Thanks for the replies, guys (and gal) ! :-) Good to know that even after 8 years in SL, I can still discover a "new" feature ! :-D Henri. From Lance.Corrimal at eregion.de Mon Aug 18 13:32:49 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 18 Aug 2014 22:32:49 +0200 Subject: [opensource-dev] Building the viewer after the latest commits Message-ID: <6877752.Mlbgsvgc4H@kumiko> Hi, Has anyone already tried to build the viewer after today's commits? For me it fails ( building on debian 6) with a few errors that look as if the boost headers and the boost libs don't match up... Invalid reference and such Any ideas? Cheers LC From nickyperian at yahoo.com Mon Aug 18 14:01:45 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Mon, 18 Aug 2014 14:01:45 -0700 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <6877752.Mlbgsvgc4H@kumiko> References: <6877752.Mlbgsvgc4H@kumiko> Message-ID: <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> I ran into an issue with boost built with gcc 4-6 and viewer compiling goo 4-7. rebuilt boost on 4.7 and no more problems. Archive and MD5 is here:?https://bitbucket.org/kokua/3p-boost-update/downloads On Monday, August 18, 2014 3:33 PM, Lance Corrimal wrote: > > >Hi, > >Has anyone already tried to build the viewer after today's commits? > >For me it fails ( building on debian 6) with a few errors that look as if the >boost headers and the boost libs don't match up... Invalid reference and such > >Any ideas? > >Cheers >LC >_______________________________________________ >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 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140818/f36df09f/attachment.htm From Lance.Corrimal at eregion.de Mon Aug 18 14:10:34 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Mon, 18 Aug 2014 23:10:34 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> Message-ID: <1488501.FQBQtFXJuB@kumiko> Hi, Thanks, I'll give that a try, Cheers LC Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > I ran into an issue with boost built with gcc 4-6 and viewer compiling goo > 4-7. rebuilt boost on 4.7 and no more problems. > > Archive and MD5 is > here: https://bitbucket.org/kokua/3p-boost-update/downloads > On Monday, August 18, 2014 3:33 PM, Lance Corrimal wrote: > >Hi, > > > >Has anyone already tried to build the viewer after today's commits? > > > >For me it fails ( building on debian 6) with a few errors that look as if > >the boost headers and the boost libs don't match up... Invalid reference > >and such > > > >Any ideas? > > > >Cheers > >LC > >_______________________________________________ > >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 From Lance.Corrimal at eregion.de Tue Aug 19 00:37:36 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 19 Aug 2014 09:37:36 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <1488501.FQBQtFXJuB@kumiko> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> Message-ID: <53F2FEC0.7020302@eregion.de> Hi, that worked. Now that needs to go into the official sources... Cheers LC Am 08/18/2014 um 11:10 PM schrieb Lance Corrimal: > Hi, > > Thanks, I'll give that a try, > > Cheers > LC > Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: >> I ran into an issue with boost built with gcc 4-6 and viewer compiling goo >> 4-7. rebuilt boost on 4.7 and no more problems. >> >> Archive and MD5 is >> here: https://bitbucket.org/kokua/3p-boost-update/downloads >> On Monday, August 18, 2014 3:33 PM, Lance Corrimal > wrote: >>> Hi, >>> >>> Has anyone already tried to build the viewer after today's commits? >>> >>> For me it fails ( building on debian 6) with a few errors that look as if >>> the boost headers and the boost libs don't match up... Invalid reference >>> and such >>> >>> Any ideas? >>> >>> Cheers >>> LC >>> _______________________________________________ >>> 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 From sldev at free.fr Tue Aug 19 04:27:25 2014 From: sldev at free.fr (Henri Beauchamp) Date: Tue, 19 Aug 2014 13:27:25 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <53F2FEC0.7020302@eregion.de> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> Message-ID: <20140819132725.5ea0edf5.sldev@free.fr> On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > > Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > > >> I ran into an issue with boost built with gcc 4-6 and viewer compiling goo > >> 4-7. rebuilt boost on 4.7 and no more problems. > > Hi, > > that worked. Now that needs to go into the official sources... Hopefully not !... The current Linux builds of the viewer and pre-built libraries are compiled with gcc 4.6, which also imposes a minimal requirement on the target systems' libstdc++ version (6.0.16). If LL were to provide pre-built libraries compiled with gcc v4.7, then the "old" (like 2 years old *only*) Linux distributions would become incapable of running the resulting viewer. You should instead keep a partition (or a VirtualBox virtual machine) with a build-system matching LL's one (i.e. using gcc 4.6.4 and its associated libstdc++). Henri. From oz at lindenlab.com Tue Aug 19 08:47:54 2014 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Tue, 19 Aug 2014 11:47:54 -0400 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <20140819132725.5ea0edf5.sldev@free.fr> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> Message-ID: <53F371AA.1080800@lindenlab.com> On 2014-08-19, 07:27 , Henri Beauchamp wrote: > On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > >>> Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: >>>> I ran into an issue with boost built with gcc 4-6 and viewer compiling goo >>>> 4-7. rebuilt boost on 4.7 and no more problems. >> Hi, >> >> that worked. Now that needs to go into the official sources... > Hopefully not !... > > The current Linux builds of the viewer and pre-built libraries are > compiled with gcc 4.6, which also imposes a minimal requirement on > the target systems' libstdc++ version (6.0.16). > > If LL were to provide pre-built libraries compiled with gcc v4.7, > then the "old" (like 2 years old *only*) Linux distributions would > become incapable of running the resulting viewer. > > You should instead keep a partition (or a VirtualBox virtual machine) > with a build-system matching LL's one (i.e. using gcc 4.6.4 and its > associated libstdc++). > > Henri. I don't want to miss an opportunity to agree with Henri... At present, our standard Linux build environment for Linux is Debian Squeeze, gcc 4.6. That's what we'll build the packages for. We expect to start a toolchain update for Windows (to VS 2013) and Mac OSX (to Xcode 5, clang) shortly, but don't plan to change Linux (it was updated much more recently than the other platforms as part of the Sunshine project). You are of course welcome to use what you want for your builds, but we won't be making changes to the packages we provide in order to support that. -- *Scott Lawrence* | /Technical Director, Second Life/ Skype ozlinden | Second Life Oz Linden Linden Lab| Makers of Shared Creative Spaces Check out what we're working on! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140819/b5b32819/attachment.htm From nickyperian at yahoo.com Tue Aug 19 09:51:19 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Tue, 19 Aug 2014 09:51:19 -0700 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <53F371AA.1080800@lindenlab.com> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> Message-ID: <1408467079.18094.YahooMailNeo@web163206.mail.gq1.yahoo.com> Yes. I agree, It does cause problems for older distros. I have been balancing the old / new distro support for some time. If I provide the old then the new users complain about every time I start libxxx.so library is missing. In some cases I provide a newer libxxx.so in the viewer package but that causes problems to as the next distro upgrade may have deprecated or removed support for libxxx.so and some distros (opensuse) nag about it. ? For a while I was building on gcc-4.6.5 on squeeze for release and then gcc-4.7 for test version in order to cover both old and new. I suspect I'll go back to that soon. ?Nicky On Tuesday, August 19, 2014 10:47 AM, Oz Linden (Scott Lawrence) wrote: > > >On 2014-08-19, 07:27 , Henri Beauchamp wrote: > >On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: >>Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: >>>I ran into an issue with boost built with gcc 4-6 and viewer compiling goo 4-7. rebuilt boost on 4.7 and no more problems. >>>Hi, that worked. Now that needs to go into the official sources... >>Hopefully not !... The current Linux builds of the viewer and pre-built libraries are compiled with gcc 4.6, which also imposes a minimal requirement on the target systems' libstdc++ version (6.0.16). If LL were to provide pre-built libraries compiled with gcc v4.7, then the "old" (like 2 years old *only*) Linux distributions would become incapable of running the resulting viewer. You should instead keep a partition (or a VirtualBox virtual machine) with a build-system matching LL's one (i.e. using gcc 4.6.4 and its associated libstdc++). Henri. >I don't want to miss an opportunity to agree with Henri... > >At present, our standard Linux build environment for Linux is Debian Squeeze, gcc 4.6.? That's what we'll build the packages for. We expect to start a toolchain update for Windows (to VS 2013) and Mac OSX (to Xcode 5, clang) shortly, but don't plan to change Linux (it was updated much more recently than the other platforms as part of the Sunshine project). > >You are of course welcome to use what you want for your builds, but we won't be making changes to the packages we provide in order to support that. > > >-- > >Scott Lawrence | Technical Director, Second Life >Skype ozlinden | Second Life Oz Linden >Linden Lab| Makers of Shared Creative Spaces >Check out what we're working on! > >_______________________________________________ >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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140819/fdeadc17/attachment-0001.htm From Lance.Corrimal at eregion.de Tue Aug 19 10:07:05 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Tue, 19 Aug 2014 19:07:05 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <20140819132725.5ea0edf5.sldev@free.fr> References: <6877752.Mlbgsvgc4H@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> Message-ID: <1685518.QcqAg21xJ6@kumiko> Well, my build environment for this kind of stuff in fact *is* a debian squeeze 6.0.10 running on KVM, and the gcc available for it is 4.4.5, not 4.6.x: debian-build-6-2:~$ cat /etc/debian_version 6.0.10 debian-build-6-2:~$ g++ --version g++ (Debian 4.4.5-8) 4.4.5 There is no newer gcc available for that version, so I dunno what the lab is doing there. It might help if the "official linux build environment asccording to LL" was properly documented somewhere on the wiki. Cheers LC Am Dienstag, 19. August 2014, 13:27:25 schrieb Henri Beauchamp: > On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > > > Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > > >> I ran into an issue with boost built with gcc 4-6 and viewer compiling > > >> goo > > >> 4-7. rebuilt boost on 4.7 and no more problems. > > > > Hi, > > > > that worked. Now that needs to go into the official sources... > > Hopefully not !... > > The current Linux builds of the viewer and pre-built libraries are > compiled with gcc 4.6, which also imposes a minimal requirement on > the target systems' libstdc++ version (6.0.16). > > If LL were to provide pre-built libraries compiled with gcc v4.7, > then the "old" (like 2 years old *only*) Linux distributions would > become incapable of running the resulting viewer. > > You should instead keep a partition (or a VirtualBox virtual machine) > with a build-system matching LL's one (i.e. using gcc 4.6.4 and its > associated libstdc++). > > Henri. From c at yotes.com Wed Aug 20 07:47:22 2014 From: c at yotes.com (Adam Moss) Date: Wed, 20 Aug 2014 15:47:22 +0100 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <53F371AA.1080800@lindenlab.com> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> Message-ID: Hiya, If someone's re-investigating/rebuilding most of the third-party libraries anyway... Isn't it a good time for the SL Linux client to go (probably exclusively) 64-bit? This wasn't true 8 years ago and wasn't quite true 4 years ago, but I think on balance it'd be a good and happy move in 2014. (IIRC several of the libraries used by the viewer are also used by the servers, which are 64-bit Linux, so there may be *less* work for LL overall in maintaining these builds, FWIW.) The 32-bit client is only marginally happy on 64-bit systems despite the compatibility layers - for example, many of the interesting and most-relevant-to-SL gstreamer audio/video codec packs on modern distros *still* install into an non-architecture-specific place, meaning you have to choose between a 32-bit (SL) or 64-bit (every other app) codec pack exclusively. In addition, building the official LL viewer on 64-bit in the absence of pre-rolled libraries is a fairly gigantuan task with results which are way off the QA'd path - personally I'll have to stoop to a 32-bit VM to continue development nowadays if I can work up the courage. Cheers, --Adam On 19 August 2014 16:47, Oz Linden (Scott Lawrence) wrote: > On 2014-08-19, 07:27 , Henri Beauchamp wrote: > > On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > > > Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > > I ran into an issue with boost built with gcc 4-6 and viewer compiling goo > 4-7. rebuilt boost on 4.7 and no more problems. > > Hi, > > that worked. Now that needs to go into the official sources... > > Hopefully not !... > > The current Linux builds of the viewer and pre-built libraries are > compiled with gcc 4.6, which also imposes a minimal requirement on > the target systems' libstdc++ version (6.0.16). > > If LL were to provide pre-built libraries compiled with gcc v4.7, > then the "old" (like 2 years old *only*) Linux distributions would > become incapable of running the resulting viewer. > > You should instead keep a partition (or a VirtualBox virtual machine) > with a build-system matching LL's one (i.e. using gcc 4.6.4 and its > associated libstdc++). > > Henri. > > > I don't want to miss an opportunity to agree with Henri... > > At present, our standard Linux build environment for Linux is Debian > Squeeze, gcc 4.6. That's what we'll build the packages for. We expect to > start a toolchain update for Windows (to VS 2013) and Mac OSX (to Xcode 5, > clang) shortly, but don't plan to change Linux (it was updated much more > recently than the other platforms as part of the Sunshine project). > > You are of course welcome to use what you want for your builds, but we > won't be making changes to the packages we provide in order to support that. > > -- > *Scott Lawrence* | *Technical Director, Second Life* > Skype ozlinden | Second Life Oz Linden > > Linden Lab | Makers of Shared Creative Spaces > Check out what we're working on! > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140820/6b27a490/attachment.htm From c at yotes.com Wed Aug 20 07:49:35 2014 From: c at yotes.com (Adam Moss) Date: Wed, 20 Aug 2014 15:49:35 +0100 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <20140819132725.5ea0edf5.sldev@free.fr> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> Message-ID: Agreed on the conservative versioning for reasons of minimal requirements and maximal compatibility - this is (was?) always a conscious goal. Ta, --Adam On 19 August 2014 12:27, Henri Beauchamp wrote: > On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > > > > Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > > > > >> I ran into an issue with boost built with gcc 4-6 and viewer > compiling goo > > >> 4-7. rebuilt boost on 4.7 and no more problems. > > > > Hi, > > > > that worked. Now that needs to go into the official sources... > > Hopefully not !... > > The current Linux builds of the viewer and pre-built libraries are > compiled with gcc 4.6, which also imposes a minimal requirement on > the target systems' libstdc++ version (6.0.16). > > If LL were to provide pre-built libraries compiled with gcc v4.7, > then the "old" (like 2 years old *only*) Linux distributions would > become incapable of running the resulting viewer. > > You should instead keep a partition (or a VirtualBox virtual machine) > with a build-system matching LL's one (i.e. using gcc 4.6.4 and its > associated libstdc++). > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140820/094e0458/attachment.htm From sldev at free.fr Wed Aug 20 08:38:18 2014 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 20 Aug 2014 17:38:18 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> Message-ID: <20140820173818.94b1e633.sldev@free.fr> On Wed, 20 Aug 2014 15:47:22 +0100, Adam Moss wrote: > Hiya, > > If someone's re-investigating/rebuilding most of the third-party libraries > anyway... > Isn't it a good time for the SL Linux client to go (probably exclusively) > 64-bit? This wasn't true 8 years ago and wasn't quite true 4 years ago, > but I think on balance it'd be a good and happy move in 2014. Are you kidding ?... I, for one, am still using 32 bits Linux (with PAE enabled, to use the full RAM and not stay limited to 4Gb), and there is a damned good reason for it: many pieces of software I'm using are quite unhappy (read: buggy) when compiled for 64 bits (I could cite Gnome v2, which I'm still using given v3 went the same UI-dumbification path as the SL v2/3 viewer, Firefox v24+ & Co). If you wish to make 64 bits builds, then fine (and yes, it'd be nice to have a set of pre-built 64 bits libraries from LL), but it's really too soon to drop 32 bits support, especially under Linux... Henri. From Lance.Corrimal at eregion.de Wed Aug 20 09:45:47 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Wed, 20 Aug 2014 18:45:47 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <20140820173818.94b1e633.sldev@free.fr> References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> <20140820173818.94b1e633.sldev@free.fr> Message-ID: <53F4D0BB.3060402@eregion.de> Am 20.08.2014 um 17:38 schrieb Henri Beauchamp: > If you wish to make 64 bits builds, then fine (and yes, it'd be nice > to have a set of pre-built 64 bits libraries from LL), but it's really > too soon to drop 32 bits support, especially under Linux... Henri. on the other hand Redhat enterprise Linux 7 isn't even available in 32bit anymore... From nickyperian at yahoo.com Sun Aug 24 19:18:55 2014 From: nickyperian at yahoo.com (Nicky Perian) Date: Sun, 24 Aug 2014 19:18:55 -0700 Subject: [opensource-dev] autobuild-largeaddress error Message-ID: <1408933135.29864.YahooMailNeo@web163206.mail.gq1.yahoo.com> this is on a win7 labtop that I don't normally build viewer on. C:\Users\bill\viewer-release>autobuild configure -c ReleaseOS -- -DLL_TESTS=OFF -DFMODEX=OFF Failed to import llsd via the llbase module; to install, use: ? pip install llbase -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140824/1ee1ab8e/attachment.htm From oz at lindenlab.com Wed Aug 27 12:02:48 2014 From: oz at lindenlab.com (Scott Lawrence (Oz Linden)) Date: Wed, 27 Aug 2014 15:02:48 -0400 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: References: <6877752.Mlbgsvgc4H@kumiko> <1408395705.64244.YahooMailNeo@web163204.mail.gq1.yahoo.com> <1488501.FQBQtFXJuB@kumiko> <53F2FEC0.7020302@eregion.de> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> Message-ID: <53FE2B58.1060109@lindenlab.com> On 2014-08-20, 10:47 , Adam Moss wrote: > Hiya, > > If someone's re-investigating/rebuilding most of the third-party > libraries anyway... > Isn't it a good time for the SL Linux client to go (probably > exclusively) 64-bit? This wasn't true 8 years ago and wasn't quite > true 4 years ago, but I think on balance it'd be a good and happy move > in 2014. Alas, we still have lots of users on systems that are running 32 bit OSes, so supporting a 64 bit build would be adding a build, not replacing one - with all the attendant increased QA and support costs. We are planning to take one step toward 64 bit support, however. I've added an --address-size option to autobuild (it modifies the platform). That will let us begin experimenting with how many of our packages can be successfully built that way. Baby steps, but we're not quite standing still. If anyone is interested in trying that version of autobuild, it's in http://bitbucket.org/oz_linden/autobuild-largeaddress That version is itself of fork of http://bitbucket.org/oz_linden/autobuild-metadata , the differences between that and the current autobuild are described at https://wiki.secondlife.com/wiki/User:Oz_Linden/Autobuild_Improvements -- *Scott Lawrence* | /Technical Director, Second Life/ Skype ozlinden | Second Life Oz Linden Linden Lab| Makers of Shared Creative Spaces Check out what we're working on! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20140827/327990ae/attachment.htm From Lance.Corrimal at eregion.de Thu Aug 28 00:45:06 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 28 Aug 2014 09:45:06 +0200 Subject: [opensource-dev] Not actually OT: How do I get/update gcc to 4.6 on debian squeeze? Message-ID: <1515073.HWJzpWbIf0@kumiko> Hi gang, How do I upgrade gcc to 4.6 on debian squeeze? And what else does need to be upgraded on debian squeeze to have the versions that LL uses? The wiki page about setting up a build environment on linux still talks about gcc 4.3... Cheers LC From Lance.Corrimal at eregion.de Thu Aug 28 06:53:43 2014 From: Lance.Corrimal at eregion.de (Lance Corrimal) Date: Thu, 28 Aug 2014 15:53:43 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <53F371AA.1080800@lindenlab.com> References: <6877752.Mlbgsvgc4H@kumiko> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> Message-ID: <9118039.VKGfyKiKUX@kumiko> Hi, So how do I get gcc 4.6 on debian squeeze? Building the whole gcc toolchain from source? Cheers LC Am Dienstag, 19. August 2014, 11:47:54 schrieb Oz Linden: > On 2014-08-19, 07:27 , Henri Beauchamp wrote: > > On Tue, 19 Aug 2014 09:37:36 +0200, Lance Corrimal wrote: > >>> Am Montag, 18. August 2014, 14:01:45 schrieb Nicky Perian: > >>>> I ran into an issue with boost built with gcc 4-6 and viewer compiling > >>>> goo > >>>> 4-7. rebuilt boost on 4.7 and no more problems. > >> > >> Hi, > >> > >> that worked. Now that needs to go into the official sources... > > > > Hopefully not !... > > > > The current Linux builds of the viewer and pre-built libraries are > > compiled with gcc 4.6, which also imposes a minimal requirement on > > the target systems' libstdc++ version (6.0.16). > > > > If LL were to provide pre-built libraries compiled with gcc v4.7, > > then the "old" (like 2 years old *only*) Linux distributions would > > become incapable of running the resulting viewer. > > > > You should instead keep a partition (or a VirtualBox virtual machine) > > with a build-system matching LL's one (i.e. using gcc 4.6.4 and its > > associated libstdc++). > > > > Henri. > > I don't want to miss an opportunity to agree with Henri... > > At present, our standard Linux build environment for Linux is Debian > Squeeze, gcc 4.6. That's what we'll build the packages for. We expect > to start a toolchain update for Windows (to VS 2013) and Mac OSX (to > Xcode 5, clang) shortly, but don't plan to change Linux (it was updated > much more recently than the other platforms as part of the Sunshine > project). > > You are of course welcome to use what you want for your builds, but we > won't be making changes to the packages we provide in order to support that. From sldev at free.fr Thu Aug 28 11:11:58 2014 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 28 Aug 2014 20:11:58 +0200 Subject: [opensource-dev] Building the viewer after the latest commits In-Reply-To: <9118039.VKGfyKiKUX@kumiko> References: <6877752.Mlbgsvgc4H@kumiko> <20140819132725.5ea0edf5.sldev@free.fr> <53F371AA.1080800@lindenlab.com> <9118039.VKGfyKiKUX@kumiko> Message-ID: <20140828201158.5f2e3daa.sldev@free.fr> On Thu, 28 Aug 2014 15:53:43 +0200, Lance Corrimal wrote: > Hi, > > So how do I get gcc 4.6 on debian squeeze? Building the whole gcc > toolchain from source? I don't know Debian distros well enough, but I suppose that their packaging system got the equivalent of rpm-based ones and allow you to grab a source package from a newer or older Debian version and recompile it under your installed version... So yes, you'd have to rebuild gcc and ancillary programs (cpp, g++, etc) and libraries (especially libstdc++), that should normally be packaged together. Note that if you are running a *newer* version of Debian (which should be the case if you have got gcc 4.7+ installed on your system), then you may even grab the binaries from the older Debian versions and install them on your system: since your glibc library will be newer than the one the older gcc was built against, the old binaries will run just fine on your system. However, note that distros usually make a distinction between the "system compiler" (the one used to build all the packages, and especially the kernel and modules for your distro version) and other (often older) compilers (sometimes required to be able to build antiquated software): you shall not overwrite your system compiler with another one when installing the latter... Rpm-based distros use different binary names for all compilers (for example: /usr/bin/gcc4.6 instead of just /usr/bin/gcc) and use "alternative" links (have a look at /etc/alternatives) to link the various compiler versions to a soft link (/usr/bin/gcc); an "update-alternatives" command is available to automatically update all the links (links to gcc, g++, cpp, libstdc++, etc must also be updated together) automatically, allowing you to easily switch from one version to another. Henri.