Re: [opensource-dev] Linux 64bit and gstreamer

[Marc Adored]

Pulseaudio is the default in all ubuntu versions. 64bit gstreamer will
not work with 32bit Secondlife Viewer even with pulseaudio because
secondlife accesses the gstreamer lib not pulseaudio. Gstreamer is the
one to access the pulseaudio subsystem. The only way to get it to work
is to build a 64bit Secondlife Viewer or hack through your system and
install a 32bit gstreamer which may or may not cause other system wide
issues so building the viewer in 64bit is the better option. Building
the viewer in 64bit is currently a really really difficult task even
for people who know what they are doing. I've been hoping for linden
to really work on simplifying the 64bit building because 64bit systems
are being more and more popular with the need for more and more
memory. I do believe someone was working on fixing this in the
opensource community but I don't recall who or how far they got.

On Fri, Dec 10, 2010 at 4:14 PM, Altair Sythos  wrote:
> On Fri, 10 Dec 2010 15:54:36 -0500
> Mike Chase  wrote:
>
>> Yes, but that doesn't address the gstreamer issue. As far as I know
>> unless something has changed.  I suppose I could bite the bullet and
>> get used to building form source.  But I was hopeful with the
>> excellent work being done in sprints by the team that a 64bit Linux
>> client might have been addressed.
>
> here work fine (on pulseaudio, but dunno if this can change something)
> ___
> 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] Linux 64bit and gstreamer

[Marc Adored]

Awesome I will checkout the latest then and try to compile it. I
wasn't aware it was even close to working. I'm excited now.

On Sat, Dec 11, 2010 at 9:12 PM, Boroondas Gupte
 wrote:
> Hi Mike,
>
> On 12/10/2010 06:51 PM, Mike Chase wrote:
>
> Can someone point me to a summary of 64bit support for Linux
> for that series of viewers?  I know in the past I was able to run a
> 32bit version but with no streaming media.
>
> See the forum thread Linux 64 bits and medias.
>
> On 12/10/2010 10:29 PM, Marc Adored wrote:
>
> I've been hoping for linden
> to really work on simplifying the 64bit building because 64bit systems
> are being more and more popular with the need for more and more
> memory. I do believe someone was working on fixing this in the
> opensource community but I don't recall who
>
> For the viewer-development branch, that'd be me. Although I mostly just
> ported others' fixes that already existed for the 1.x code base and/or
> Snowglobe 2.
>
>  or how far they got.
>
> Should be fully working now (see below), if you start form
> viewer-development (or viewer-beta or viewer-release). About the
> mesh-development branch ... well, that's another animal entirely when it
> comes to building 64bit (due to new dependencies and whatnot).
>
>
> On 12/11/2010 04:46 AM, Mike Chase wrote:
>
> On 12/10/2010 08:06 PM, Carlo Wood wrote:
>
> Huh huh... No need to install 32bit libs! Just compile the viewer
> yourself! I've been running native 64 bit since day one.
>
> Carlo, do you have a script or a pointer to the steps to do the build?
>
> All necessary steps should be on the wiki at Compiling the viewer (Linux).
>
> Is it simply the standard steps or something special.
>
> Because Linden Lab does not provide pre-built libraries for 64bit linux,
> you'll have to build "standalone", i.e., using system libraries. (See What
> does 'Standalone' mean?) Thus you'll need to have all build time
> dependencies installed into your system. The wiki article linked above lists
> debian and ubuntu package names for most dependencies. Standalone-specific
> steps are included and marked as such (e.g. through section naming).
>
> The build documentation tends to get out-of-date quickly. If you decide to
> build yourself and run into troubles or have further questions, please do
> ask on this mailing list or on IRC (channel #opensl on freenode) so that you
> can be helped and the documentation improved/corrected.
>
> Good luck & cheers,
> Boroondas
>
> ___
> 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] Linux 64bit and gstreamer

[Marc Adored]

Yes 32bit SLVoice can run with 64bit viewer because the viewer is not
using it as a lib its a network connection between each other so none
of that matters.

On Sun, Dec 12, 2010 at 9:03 PM, Mike Chase
 wrote:
> On 12/12/2010 04:09 PM, Argent Stonecutter wrote:
>> You know what would really help people get over the hump of setting up for 
>> building SL?
>>
>> A VMware appliance containing a working SL build environment, for 32 and 64 
>> bit Linux.
> Or a KVM/qemu image assuming the target audience is running 64bit Linux.
>
> On a related note, the voice components are proprietary.  Is it possible
> to get them to work?  Can you use a 32 voice and SLPlugin component with
> the 64bit application?
>
> Mike
>
> ___
> 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

[opensource-dev] streaming media on 64bit?

[Marc Adored]

I am on 64bit ubuntu and noticed that media on a prim works now even
though I am using a 32bit viewer. I am assuming this is because it is
a SLPlugin and not part of the viewer? I was wondering if the
streaming audio/video that has not worked for 32bit viewers on 64bit
systems could be reworked to work the same way? Is there plans for
this? I think that with the refusal to work on a 64bit viewer this
would be a good compromise because that is the only reason I require a
64bit built viewer.

I just thought I would probe here first before messing with jiras :)
___
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] streaming media on 64bit?

[Marc Adored]

So maybe someone should provide a download of the needed 32bit
gstreamer libraries :) I think that if linden did this sort of like
Pheonix does with the SLVoice where the first launch it downloads any
extra libraries and puts them in the libs/bins folder. Is this a
practice linden might be interested in?

On Sat, Feb 5, 2011 at 5:47 AM, Boroondas Gupte
 wrote:
> Hi Marc
>
> On 02/05/2011 05:03 AM, Marc Adored wrote:
>
> I am on 64bit ubuntu and noticed that media on a prim works now even
> though I am using a 32bit viewer. I am assuming this is because it is
> a SLPlugin and not part of the viewer?
>
> That's not the reason: The SLPlugin binary, while a separate process than
> the viewer main binary, is also shipped only compiled for 32bit in the
> official downloads and thus faces the same problem as the main binary: it
> can only load 32bit libraries. The reason why it can display web content
> anyway, is that the library used for rendering html is also included (also
> in 32bit) in the download.
>
> I was wondering if the
> streaming audio/video that has not worked for 32bit viewers on 64bit
> systems could be reworked to work the same way?
>
> For audio/video stream display, the GStreamer libraries are used, but those
> aren't included in the download. So SLPlugin tries to load the
> system-installed version (if any), which (if SLPlugin is compiled for 32bit)
> can only succeed if those libs are compiled for 32bit, too.
>
> So the possibilities would be:
>
> Include 32bit GStreamer libraries in the official download (or in a separate
> download)
>
> Around 17 MB including common plugins, but still excluding any dependency
> libraries that might have to be added for this to work, too
>
> Offer SPLugin (and maybe the whole viewer) compiled for 64bit, too
>
> This would mean additional QA work for LL.
>
> Have Linux 64bit users install a 32bit GStreamer
>
> Probably difficult on many distributions (because GStreamer is usually not
> part of the 32bit compatibility bundles, such as ia32-libs)
>
> (I've gone into more detail about the options from the users' point of view
> in past explanations.)
>
> Is there plans for this?
>
> I don't know of any specific one. There's a feature request for offering
> official 64bit downloads: VWR-13793.
>
>  I think that with the refusal to work on a 64bit viewer this
> would be a good compromise because that is the only reason I require a
> 64bit built viewer.
>
> That would indeed make life much easier for non-technical Linux 64bit users.
>
> I just thought I would probe here first before messing with jiras :)
>
> Although this has been discussed in the past, it's good that someone brings
> it up again.
>
> Cheers,
> Boroondas
>
___
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] streaming media on 64bit?

[Marc Adored]

This is the error I get:

 pid:5205: (media plugin) grab_gst_syms:93: Found DSO: libgstreamer-0.10.so.0
 pid:5205: (media plugin) grab_gst_syms:107: Found DSO: libgstvideo-0.10.so.0

(:5205): GStreamer-WARNING **: Failed to load plugin
'/usr/lib32/gstreamer-0.10/libgstspc.so': libopenspc.so.0: cannot open
shared object file: No such file or directory
 pid:5205: (media plugin) MediaPluginGStreamer010:170:
MediaPluginGStreamer010 constructor - my PID=5205
 pid:5205: (media plugin) receiveMessage:1000: GStreamer010 media
instance failed to set up
2011-02-05T15:04:29Z INFO: LLPluginProcessParent::receiveMessage:
plugin version string: GStreamer010 media plugin, GStreamer version
0.10.30.0 (runtime), 0.10.6.0 (headers)
 pid:5205: (media plugin) receiveMessage:1216:
MediaPluginGStreamer010::receiveMessage: unknown message class:
media_browser
 pid:5205: (media plugin) receiveMessage:1216:
MediaPluginGStreamer010::receiveMessage: unknown message class:
media_browser
 pid:5205: (media plugin) receiveMessage:1216:
MediaPluginGStreamer010::receiveMessage: unknown message class:
media_browser
 pid:5205: (media plugin) receiveMessage:1216:
MediaPluginGStreamer010::receiveMessage: unknown message class:
media_browser
 pid:5205: (media plugin) receiveMessage:1216:
MediaPluginGStreamer010::receiveMessage: unknown message class:
media_browser
 pid:5205: (media plugin) receiveMessage:1027:
MediaPluginGStreamer010::receiveMessage: shared memory added, name:
/LL5174_3, size: 8, address: 0xf732e000
 pid:5205: (media plugin) receiveMessage:1107: >Got size change
instruction from application with shm name: /LL5174_3 - size is 1 x 1
 pid:5205: (media plugin) receiveMessage:1123: *** Got size change
with matching shm, new size is 1 x 1
 pid:5205: (media plugin) receiveMessage:1124: *** Got size change
with matching shm, texture size size is 1 x 1


I have copied the gstreamer-0.10 from my wifes 32bit ubuntu to
/usr/lib32/gstreamer-0.10 but it still cant find the file
/usr/lib32/gstreamer-0.10/libgstspc.so. I have verified it is there so
I am not sure why it can't find it. I also put all the gstreamer libs
into the lib of sl folder and it still can not find it :/ I know she
has all the proper gstreamer plugins installed also because streaming
media works for her so theoretically it should work for me. From that
message it just looks like its not finding the files...
___
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] streaming media on 64bit?

[Marc Adored]

On Sat, Feb 5, 2011 at 10:48 AM, Altair Sythos  wrote:
> On Sat, 5 Feb 2011 10:15:35 -0500
> Marc Adored  wrote:
>
>> I have copied the gstreamer-0.10 from my wifes 32bit ubuntu to
>
> very bad idea

Not really I didn't overwrite my libs in /usr/lib i put them in
/usr/lib32 where they belong and its the same version/distro of ubuntu
so it should be fine.

>
>> /usr/lib32/gstreamer-0.10 but it still cant find the file
>> /usr/lib32/gstreamer-0.10/libgstspc.so. I have verified it is there so
>> I am not sure why it can't find it. I also put all the gstreamer libs
>
> you need to install ia32libs, this bundle a ot of 32bit libraries to
> handle this kind of problems, install the package "linux32" too, may be
> nice and usefull run the viewer within it

I have ia32libs installed but it doesnt install a 32bit gstreamer sadly.
___
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] Copying GStreamer from a 32bit system to a 64bit one (was: streaming media on 64bit?)

[Marc Adored]

SUCCESS! Ok so I found this wonderful program called getlibs. I've
used it before and I tried to get gstreamer stuff installed but failed
but I figured it out this time. I used this command to get a list of
all my 64bit gstreamer stuff installed:

apt-cache show gstreamer* |grep "Package: gstreamer"

With that command I got a list and ran this command:

getlibs -p gstreamer-tools gstreamer0.10-alsa gstreamer0.10-doc
gstreamer0.10-esd gstreamer0.10-gnonlin gstreamer0.10-gnonlin-dbg
gstreamer0.10-gnonlin-doc gstreamer0.10-nice
gstreamer0.10-plugins-base gstreamer0.10-plugins-base-apps
gstreamer0.10-plugins-base-dbg gstreamer0.10-plugins-base-doc
gstreamer0.10-plugins-good gstreamer0.10-plugins-good-dbg
gstreamer0.10-plugins-good-doc gstreamer0.10-pulseaudio
gstreamer0.10-tools gstreamer0.10-x gstreamer-dbus-media-service
gstreamer0.10-buzztard gstreamer0.10-buzztard-doc gstreamer0.10-ffmpeg
gstreamer0.10-ffmpeg-dbg gstreamer0.10-fluendo-mp3
gstreamer0.10-gnomevfs gstreamer0.10-packagekit
gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-dbg
gstreamer0.10-plugins-bad-doc gstreamer0.10-plugins-cutter
gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-dbg
gstreamer0.10-plugins-ugly-doc gstreamer0.10-pocketsphinx
gstreamer0.10-sdl gstreamer0.10-plugins-bad-multiverse
gstreamer0.10-plugins-bad-multiverse-dbg
gstreamer0.10-plugins-ugly-multiverse
gstreamer0.10-plugins-ugly-multiverse-dbg gstreamer0.10-packagekit
gstreamer0.10-fluendo-plugins-mp3-partner

Yeah its a long command and it takes awhile to execute. The only
package it failed to fetch was
gstreamer0.10-fluendo-plugins-mp3-partner_7.0.20100316-3_i386 which I
downloaded from

http://pkgs.org/download/ubuntu-10.04/canonical-partner-i386/gstreamer0.10-fluendo-plugins-mp3-partner_7.0.20100316-3_i386.deb.html

and then installed it like so:

getlibs -i gstreamer0.10-fluendo-plugins-mp3-partner_7.0.20100316-3_i386.deb

Then started secondlife and I had streaming audio!

Now I will say that that list above could be cleaned up to only
install what secondlife needs but I just did it all to get it working.
I am sure some of those packages are duplicates also. Anyone who cares
to clean it up go ahead I just got it working :P

Also you probably need to install the 32bit compatibility packages
first and of course you'll need to install getlibs. It used to be at
http://frozenfox.freehostia.com/cappy/ but that link is broke and I am
not sure if its in the default ubuntu repos :/ It shows up in mine but
I don't know if that is because the package was installed from that
link. I have had it on my machine for a long time.

Hope this helps everyone :)








On Sat, Feb 5, 2011 at 10:29 AM, Boroondas Gupte
 wrote:
> On 02/05/2011 04:15 PM, Marc Adored wrote:
>> (:5205): GStreamer-WARNING **: Failed to load plugin
>> '/usr/lib32/gstreamer-0.10/libgstspc.so': libopenspc.so.0: cannot open
>> shared object file: No such file or directory
>>
>> [...]
>>
>> I have copied the gstreamer-0.10 from my wifes 32bit ubuntu to
>> /usr/lib32/gstreamer-0.10 but it still cant find the file
>> /usr/lib32/gstreamer-0.10/libgstspc.so.
> GStreamer is not failing to find libgstspc.so ... ratherlibgstspc.so is
> failing to find libopenspc.so.0 ...
>
> GStreamer is not self-contained: It (or its plugins) uses a lot of
> shared libraries that aren't part of GStreamer itself (and thus not in
> its directory but somewhere else on the system).
>
> Cheers,
> Boroondas
>
___
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] Autobuild install can't install 3p-kdu-private

[Marc Adored]

kdu cannot be downloaded or distributed legally unless you have a
licence. I ran into the problem the other day you have to disable kdu
so it uses openjpeg.

Use -- -DUSE_KDU:BOOL=FALSE

I am not sure how to use that in windows but you may know how.


On Wed, May 4, 2011 at 1:10 AM, xinyi chen  wrote:
> Platform: windows
> IDE: vs2010
> When I run the command to install all dependencies , it 's broken here:
> Failed to
> download http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-kdu-private/rev/221672/arch/CYGWIN/installer/kdu-6.4.1-windows-20110218.tar.bz2
> So where should I manually download the lib from?
> is there a way to resolve the problem?
>
> Thanks in advance
> Simon
> ___
> 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

[opensource-dev] ATI vs NV vs OSX

[Marc Adored]

So I am building a machine we shall call it a haxintosh... It will be
running OSX I was just wondering if ATI or Nvidia was better supported
for SecondLife on OSX? I know OSX chose ATI for there machines but
does SL support it or would I be better off to get Nvidia anyways? I
really want everything shadows lighting all that. Ive seen issues on
OSX for some people but I dont know if its ATI or SL's problems with
the os directly. I know this is the opensource dev list but I figured
you guys would know this stuff better then anyone being in the
trenches and all :P
___
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] ATI vs NV vs OSX

[Marc Adored]

So does that mean no shadows no matter the card in osx?

On Wed, May 11, 2011 at 3:57 AM, Francesco "Sythos"  wrote:
> Lion (next macosx release) have OpenGL upgraded from 2.1 to 3.1 and
> Apple have enabled GL_ARB_shadow &C. (already in 2.1 but disabled for
> Apple decision), this mean by *theory* all OpenGL glsl can work on Mac
> too (imho, never checked deeply inside glsl of the viewer)
>
> --
> Sent by iPhone
>
> Il giorno 11/mag/2011, alle ore 09:20, Marc Adored
>  ha scritto:
>
>> So I am building a machine we shall call it a haxintosh... It will be
>> running OSX I was just wondering if ATI or Nvidia was better supported
>> for SecondLife on OSX? I know OSX chose ATI for there machines but
>> does SL support it or would I be better off to get Nvidia anyways? I
>> really want everything shadows lighting all that. Ive seen issues on
>> OSX for some people but I dont know if its ATI or SL's problems with
>> the os directly. I know this is the opensource dev list but I figured
>> you guys would know this stuff better then anyone being in the
>> trenches and all :P
>> ___
>> 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] ATI vs NV vs OSX

[Marc Adored]

Right now I m running a haxintosh and I get poor performance but I can
still turn shadows on. I am running on a AMD Athlon x2 and a geforce
8800gs. I am upgrading to a intel i7 sandy bridge and was just trying
to figure out what card would be best suited for osx and SL. Thanks
for the input guys. From what I've been told from the haxintosh
community is that the geforce 2xx's perform better then the 3xx and
4xx cards on osx. The most recommended card is a GTX-280 or 285 so I
think that will be my choice. Thanks again guys :)

On Wed, May 11, 2011 at 2:24 PM, Trilo Byte  wrote:
> Caveat - shadows are still in the experimental stages at LL, even moreso on
> the Mac (as I understand it, the team doing that work within LL has little
> to no access to Mac hardware for testing and experimentation).
> Shadows currently work on nVidia Macs with the following GPU's: GeForce
> 9400m, GeForce 9600m GT, GT-120, GT-320M, GT-330M, and GTX-285.  The Quadro
> 4000 supports shadows when running the Windows SL client under boot camp or
> even in the Parallels virtual machine, but not reliably on the Mac client.
>  I've heard mixed reports about shadows working on the GeForce 8800GT.
> They do not work yet on any ATI Mac when running the Mac client, though
> there are plans to fix that at some point.  It is not a case of waiting on a
> change in drivers on Apple's end, but changes and improvements to the code
> on LL's end.  Since the team involved with getting that moving are also the
> same folks tasked with working on mesh (an understandably higher priority
> project), it's moving slowly.  Then add the stuff I mentioned in the caveat
> (it's still considered experimental which makes it 'back-burner' status,
> plus they don't have the proper equipment to be able to test and experiment
> internally).
> From a hardware and OS/driver/OpenGL standpoint, both nVidia and ATI's
> hardware are more than capable of doing the job under either version of the
> OS (the professional 3D rendering apps don't seem to have any trouble with
> shadows, depth of field, or global illumination on any reasonably powerful
> card), the issue is in the SL application code.
> On May 11, 2011, at 12:20 AM, Marc Adored wrote:
>
> So I am building a machine we shall call it a haxintosh... It will be
> running OSX I was just wondering if ATI or Nvidia was better supported
> for SecondLife on OSX? I know OSX chose ATI for there machines but
> does SL support it or would I be better off to get Nvidia anyways? I
> really want everything shadows lighting all that. Ive seen issues on
> OSX for some people but I dont know if its ATI or SL's problems with
> the os directly. I know this is the opensource dev list but I figured
> you guys would know this stuff better then anyone being in the
> trenches and all :P
> ___
> 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] in-viewer translation is dead soon.

[Marc Adored]

I think the main issue here is abuse due to bad coding. The real
discussion should not be who it needs to move to or what other service
can be abused next it should be how do we write better code to lesson
the burden on whatever service we use. Secondlife has a LARGE userbase
therefore any usage will be great but what can we do to make that
usage more efficient Just think... right now every user who has
machine translation enabled for google is translating every line of
text they read. Even if someone else already translated it. Thats
thousands of queries per second. None of that load makes any money for
google or microsoft for that matter. So the service being abused on
top of no revenue is kind of a slap in the face. SO maybe some thought
into making the code a little better should be done first. Maybe some
type of central caching service... I know security issues security
issues but I am just throwing out ideas. Because to me 1500 different
people translating the same line of text is just abuse and retarded.
Maybe some kind of central proxy from secondlife can be setup so if
the same line of text is queried it just spits out the translation
thats cached to them. The cache lifetime should be short for security
purposes but caching a translation for 5mins should be plenty of time
for everyone receiving that text to get the cache translation. Just
think of how much of a burden that will remove from google. I know it
will put more of a burden on a secondlife server somewhere but not
that much because its just spitting out cache its not like its
translating any text or anything just serving cached data. You could
even tell each TPV that if they want to offer translations they have
to setup some type of caching. Hell it could probably even be some
simple proxy with a decent cache time setup. I don't know the
specifics but I know it can be done better. Sadly what has happened
here is what happens when you don't put limits on a service. Crappy
code is written and the service is abused. I am sure that google
simply throttling the api will make quite a bit of better code emerge
from the depths... That may even be Googles plan and why such a long
period before its shut off completely. SO maybe the thought pattern
should be "how can we do what we're doing better" instead of "who can
we jump ship to next and abuse" Because like others have said google
is a very big company, bandwidth is very easy to come by for them so
if we are hurting them then its going to be worse for others. No body
is better suited for such a task then google. Just my $0.02 :)

On Sat, May 28, 2011 at 9:32 AM, Daniel  wrote:
> The problem as pointed out by Tateru Nino on her blog is that Google is
> huge, and their
> users will "fail over" to other services like you are suggesting,
> causing them to get overloaded
> also.  In that case, they may also decide it is too expensive to stay
> open, causing a chain
> reaction.
>
> Note that Google is not closing off all translation services.  They are
> moving to using the
> Translate Element within web pages (
> http://translate.google.com/translate_tools ).  I assume
> the reason is a freestanding translator page does not bring in any
> revenue, while a web page element
> on pages that carry their adsense ads increases how many of their ads
> can be read by people around
> the world (ie makes money for them).
>
> The question is can you incorporate that web element as a substitute for
> what you are using now?
>
>> From: "Philippe (Merov) Bossut"
>> Subject: Re: [opensource-dev] in-viewer translation is dead soon.
>>
>> Hi,
>>
>> It shouldn't be too hard to substitute with another service. Someone has an
>> alternative service to propose?
>>
>> Cheers,
>> - 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] in-viewer translation is dead soon.

[Marc Adored]

I like that idea on translate what they want. Also that translating
your own text for you is what im talking about. Wastefulness because
no restrain was made and yes it should only translate text coming from
a viewer with a different language set. This things along with some
caching would make it very little burden on the provider.

On Sat, May 28, 2011 at 5:44 PM, Starfire  wrote:
> Just curious...  why translate anything if everyone within hearing range
> have the same language set up?
>
> And why is it trying to translate my own typing for me to see?  "Me: ty
> (company)"
>
> How about an option in the history window (or somewhere) where you can
> choose a line of text and request a translation for it?
>
>
> ___
> 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] in-viewer translation is dead soon.

[Marc Adored]

I think the reason you think some book(s) might be more then what SL
would do to google translator is because you have no idea how much
text chat traffic SL has. It is way more text then and whole series of
books could have every few minutes really. I dont think anyone has
said it was SL that has caused google to do what its doing but merely
has contributed to it. Also what you need to understand is you
translating a book is 1 or 2 requests or a few more depending but SL
is a new request every line of text. Its much easier to handle 1
request with a lot of text then it is to handle tons of small
requests. I think googles problem is with the abuse like there
statement says but the abuse came from no regulation. One thing I am
not sure about is why google is just shutting it down instead of
making the throttling permanent...

On Sat, May 28, 2011 at 11:52 PM,   wrote:
> Hey Everybody,
>
> i don't know if i misunderstood or not, but are you really talking about
> Google translation services particularly picking on SL access?  All the
> mail sounded to me like it was more of a policy decision at Google
> affecting everyone everywhere?
>
> It seems to me that way worse abuse has been stuff like i should be
> ashamed to admit, people like me stuffing through whole books from foreign
> languages into the translator for our classes.  It seems like if Google is
> complaining about stuff the few thousand one-liners from SL in a day
> aren't that much compared to even one of the books i uh, "know about."
>
> Actually, considering what SL is and all that, you'd think Google would be
> into supporting it.  What am i missing?
>
> - AK
>
> 
>
> I think the main issue here is abuse due to bad coding. The real
> discussion should not be who it needs to move to or what other service
> can be abused next it should be how do we write better code to lesson
> the burden on whatever service we use. Secondlife has a LARGE userbase
> therefore any usage will be great but what can we do to make that
> usage more efficient Just think... right now every user who has
> machine translation enabled for google is translating every line of
> text they read. Even if someone else already translated it. Thats
> thousands of queries per second. None of that load makes any money for
> google or microsoft for that matter. So the service being abused on
> top of no revenue is kind of a slap in the face. SO maybe some thought
> into making the code a little better should be done first. Maybe some
> type of central caching service... I know security issues security
> issues but I am just throwing out ideas. Because to me 1500 different
> people translating the same line of text is just abuse and retarded.
> Maybe some kind of central proxy from secondlife can be setup so if
> the same line of text is queried it just spits out the translation
> thats cached to them. The cache lifetime should be short for security
> purposes but caching a translation for 5mins should be plenty of time
> for everyone receiving that text to get the cache translation. Just
> think of how much of a burden that will remove from google. I know it
> will put more of a burden on a secondlife server somewhere but not
> that much because its just spitting out cache its not like its
> translating any text or anything just serving cached data. You could
> even tell each TPV that if they want to offer translations they have
> to setup some type of caching. Hell it could probably even be some
> simple proxy with a decent cache time setup. I don't know the
> specifics but I know it can be done better. Sadly what has happened
> here is what happens when you don't put limits on a service. Crappy
> code is written and the service is abused. I am sure that google
> simply throttling the api will make quite a bit of better code emerge
> from the depths... That may even be Googles plan and why such a long
> period before its shut off completely. SO maybe the thought pattern
> should be "how can we do what we're doing better" instead of "who can
> we jump ship to next and abuse" Because like others have said google
> is a very big company, bandwidth is very easy to come by for them so
> if we are hurting them then its going to be worse for others. No body
> is better suited for such a task then google. Just my $0.02 :)
>
> On Sat, May 28, 2011 at 9:32 AM, Daniel  wrote:
>> > The problem as pointed out by Tateru Nino on her blog is that Google is
>> > huge, and their
>> > users will "fail over" to other services like you are suggesting,
>> > causing them to get overloaded
>> > also.  In that case, they may also decide it is too expensive to stay
>> > open, causing a chain
>> > reaction.
>> >
>> > Note that Google is not closing off all translation services.  They are
>> > moving to using the
>> > Translate Element within web pages (
>> > http://translate.google.com/translate_tools ).  I assume
>> > the reason is a freestanding translator

Re: [opensource-dev] in-viewer translation is dead soon.

[Marc Adored]

Yes the API is being shut off completely. Not just that simple
translation page most see. The Viewer uses the api so thats why it
effects the viewer and tons of other apps. Its not just about
monitization although I am sure it is part of it. The API is extremely
abused not just by Secondlife and I never said it was just SecondLife.
Also my suggestions are not to change Googles mind but to make our
code better so whoever we have to use in the future whether its Google
or another that we put less burden on them so that the service last
longer.

I personally think that Linden licencing the service from google would
be a very good solution. They may also be able to work with google to
make a better library and caching system.

On Sun, May 29, 2011 at 9:37 AM, Argent Stonecutter
 wrote:
>
> On 2011-05-29, at 06:39, Daniel wrote:
>
>> You didn't read my previous comment apparently.  They are NOT shutting
>> off all translations.
>> They are shutting the freestanding translation page in favor of embedded
>> translation web
>> elements within pages.
>
> That's not what I read.
>
> What I read is they're shutting off the API.
>
> http://code.google.com/apis/language/translate/overview.html
>
>
___
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

[opensource-dev] compiling viewer-external with ubuntu lucid 64bit

[Marc Adored]

I was wondering if anybody had any success compiling snowglobe on
ubuntu lucid 64bit and if they have what steps they took to prepare their system
for it. I have installed everything under the sun and my /usr/include
folder is a mess and I still can't get it to compile in 64bit or
32bit.

./develop.py -m64 -t Release
Gives me no errors until I do

./develop.py -m64 -t Release build then it gets to

-- snip --
[ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/metaproperty.o
[ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/reflective.o
[ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/timing.o
[ 10%] Building CXX object llcommon/CMakeFiles/llcommon.dir/u64.o
Linking CXX shared library libllcommon.so
/usr/bin/ld: cannot find -lbreakpad_client
collect2: ld returned 1 exit status
make[2]: *** [llcommon/libllcommon.so] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2


 and it fails. The output above is from me going into
viewer-linux-x86_64-release and compiling with make to get the
individual error because ./develop.py doesn't provide it. When I build
with

./develop.py -m32 -t Release

-- snip --
-- Version of viewer is 2.1.0.206484
-- Configuring done
CMake Warning at newview/CMakeLists.txt:1393 (add_executable):
 Cannot generate a safe linker search path for target secondlife-bin because
 files in some directories may conflict with libraries in implicit
 directories:

   link library [libGLU.so] in /usr/lib may be hidden by files in:
     
/media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client

 Some of these libraries may not be found correctly.


CMake Warning at integration_tests/llui_libtest/CMakeLists.txt:53
(add_executable):
 Cannot generate a safe linker search path for target llui_libtest because
 files in some directories may conflict with libraries in implicit
 directories:

   link library [libGLU.so] in /usr/lib may be hidden by files in:
     
/media/Storage/src/snowglobe/viewer-external/indra/../libraries/i686-linux/lib_release_client

 Some of these libraries may not be found correctly.


-- Generating done
-- Build files have been written to:
/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-i686-release


Which I assume is not good but it generated everything fine so I continue with

./develop.py -m32 -t Release build

and get:


[  0%] Built target cmake
[  1%] Built target llaudio
[  1%] Built target llcommon_tests
[  4%] Built target stage_third_party_libs
Linking CXX shared library libllcommon.so
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for
-lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for
-lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for
-lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for
-lstdc++
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-linux-gnu/4.3.4/../../../libstdc++.so when
searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/libstdc++.so when
searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
make[2]: *** [llcommon/libllcommon.so] Error 1
make[1]: *** [llcommon/CMakeFiles/llcommon.dir/all] Error 2
make: *** [all] Error 2

This is also after going into viewer-linux-i686-release and compiling
with make to see what the actual error was.

If anyone can help that would be greatly appreciated :) I really would
like to get a 64bit version compiled so I have my gstreamer back but
32bit will do. I am trying to also start dev work in snowglobe too. I
will note that I can successfully compile emerald viewer which is
based on snowglobe 1.4 code.
___
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] compiling viewer-external with ubuntu lucid 64bit

[Marc Adored]

Just tried that and got same error. Its not a missing .h file or
anything just seems like no Makefile for libsndfile.so.1 is being
generated during the configure maybe

On Wed, Jul 7, 2010 at 10:54 AM, Aleric Inglewood
 wrote:
> install libsndfile1-dev
>
> On Tue, Jul 6, 2010 at 7:54 PM, Marc Adored  wrote:
>>
>> On Tue, Jul 6, 2010 at 7:35 AM, Aleric Inglewood
>>  wrote:
>> --snip--
>> >
>> > Viewer external? That isn't snowglobe.
>> >
>> >
>>
>> Yeah apparently view-external is 2.1 not snowglobe and its broke for
>> linux right now. I am going to try your suggestions with
>> viewer-external source anyways to see if I can it to compile because I
>> have managed to patch most of the broke parts of it and I'm not
>> getting the breakpad error anymore now I'm getting:
>>
>> [  0%] Built target llaudio
>> make[2]: Entering directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[2]: Entering directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[2]: Leaving directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[2]: Leaving directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[2]: Entering directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[2]: *** No rule to make target
>> `../newview/vivox-runtime/i686-linux/libsndfile.so.1', needed by
>> `llcommon/libsndfile.so.1'.  Stop.
>> make[2]: Leaving directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make[1]: *** [llcommon/CMakeFiles/stage_third_party_libs.dir/all] Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [  2%] Built target llmath
>> make[1]: Leaving directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> make: *** [all] Error 2
>> make: Leaving directory
>>
>> `/media/Storage/src/snowglobe/viewer-external/indra/viewer-linux-x86_64-release'
>> Error: the command 'make' exited with status 2
>
>
___
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] V2.X & V1.X support on the same machine

[Marc Adored]

On Thu, Aug 5, 2010 at 8:43 PM, Bunny Halberd  wrote:
> On Thu, Aug 5, 2010 at 10:12 AM, Dzonatas Sol  wrote:
>
>> As a kid, I loved playing go fish, and then gin, and then gin rummy, and
>> rummy, and then rummykub. =)
>
> Am I accidently filtering part of this list? This is not the first
> message I've gotten that seems completely out of context...
>
> - Bunny

I'm with you Bunny the last few messages haven't made hardly any sense
at all. I know it has something to do with some card games, MOAP and
apple but what do they all have in common and is it relevant to
opensource-dev?
___
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] Pie menu ideas (was: Re: Open Viewer Development Announcement)

[Marc Adored]

On Thu, Aug 19, 2010 at 6:40 AM, Opensource Obscure  wrote:
--snip--
>
> As always, providing users with the ability to choose a different
> system (that is, pie menu) may be ideal - but again, this shouldn't
> have an high priority.

I agree with that. Maybe a simple debug setting or a checkbox or
dropdown box to choose Pie Menu or Standard Menu
___
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] Malicious payloads in third-party viewers: is the policy worth anything?

[Marc Adored]

This was an attempt to do 1 of 2 things or both. There is no denying
it because every other "excuse" I've seen is pure bull and doesn't
even make sense. The person responsible for doing this was either
arrogant enough to think that the userbase was large enough and there
was enough people logging in that putting links to a site could cause
it issues or they figured the extra traffic could financially harm the
person paying for the service or both. This crap about boasting
traffic I really don't get. I don't see why anyone would accept
something that doesn't even make sense. How are you boasting traffic
by hiding any knowledge of what your doing to boast? How is any person
that matters going to notice a bunch of hidden iframes on the login
page? Where they boasting to the owner of the website? There are much
more legal ways of "boasting" your traffic. They did post traffic
stats which is what I see as boasting but hiding iframes isn't even in
the same ballpark as boasting. It was a pissing match between 2 or
more devs on different projects and they used their userbase in
illegal activity. People saying it was "hardly" a DDos are trying to
discredit what it was. When it comes to laws there really isn't no
"kind of" breaking the law. Just because someones arrogance prevents
them from doing something successfully doesn't make the attempt any
less illegal. If you steel something from a store and get caught
before you leave the store you still get in trouble. Also discrediting
the victim was not a bright idea either because frankly it doesn't
matter not one bit who the victim was or what they are guilty of. The
old saying stands here 2 wrongs don't make a right. Linden must act
according to this. They should not be biased in any manor.

The facts are emerald violated the trust of their users and they have
done so a few times and do nothing to correct the problem. They
violated the TPV policy a few times also that should at least warrant
removal from the TPV list AT LEAST. I wouldn't recommend banning the
client because a lot of people use it but removing them from the TPV
list will definitely send a message and maybe MAYBE they will try to
fix the structure of the project so that someone can be held
responsible for changes to important parts of the viewer. Also I would
think that the emdku crap they are putting in the viewer violates the
TPV simply because no body can see what gets added because of it. They
could be transmitting every bit of our information somewhere and no
body knows. I wouldn't put it past some of the devs after what I've
seen and the secrecy that is growing from within.

I want everyone to know that I am not an emerald hater. I love emerald
and I still use it occasionally but I only use a copy I have compiled
myself. I do not trust dev's of an opensource project who have
something they want to hide from everyone specially ones with the
backgrounds of certain dev's on the emerald team.

I would also like to say that had this been a "first offence" it might
be different and the "we didnt know" excuse might have flown but
considering there are a few dev's that have had repeated headlines
that make them out to be liars and script kiddies with known "not so
legal" retaliation habits a bit more drastic measures should be taken.
its like disciplining your child. if you threaten and threaten but
never act eventually they learn they can do whatever they want and not
get in trouble. the TPV means nothing if its not enforced.
___
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] This is how Linden Lab treats it's customers...

[Marc Adored]

Can you guys please take the topic elsewhere its hard to catch whats
relevant with everyone discussing this off topic thread. I'm sure
there is a sl-dr...@lists.secondlife.com or similar available for
ranting about customer service and business practices but if I'm not
mistaken this list is for opensource development of the sl viewer.
Thank you for not filling my opensource-dev folder with any more of
this :)

- fellow former land owner that lost $250 all at once to 3rd party
land purchase scam

On Sat, Aug 28, 2010 at 3:56 PM, Dahlia Trimble  wrote:
> After reading this thread, somehow all my past bad memories from being a
> mainland resident no longer seem quite so bad.
>
> On Sat, Aug 28, 2010 at 11:21 AM, Carlo Wood  wrote:
>>
>> Sorry, but you are ignorant.
>>
>> A running sim is being paid for. That money is paid to Linden Lab.
>> It doesn't matter if that money was first paid by a grandmother to
>> her grandson, then double by gambling in the casino and subsequently
>> paid to some random stranger on Xstreet who give L$ for it, which
>> then were paid to some untrusty game-landlord who gave the game
>> money to yet another random stranger on Xstreet for which he recceived
>> real dollars which then finally are paid to Linden Lab.
>>
>> Namely, if the guy actually using the sim doesn't want to pay for
>> it, the sim can't run. The fact that it runs means someone pays
>> for it and you can bet on it that that comes from the wallet of the
>> person using it (living on it).
>>
>> So, in this case the sim was running a year aka $100 per month.
>> Now the sim isn't running anymore and this income of LL stopped.
>>
>> The renter then offers to continue renting it for $100 per month,
>> by paying *directly* to LL, but that is not accepted.
>>
>> It is this last thing that is ridiculous. Or at the VERY LEAST it
>> should be (or have been) possible to rent an isolated/private homestead
>> directly from Linden Lab.
>>
>> Don't say that 'L$' isn't real money so one has no rights. This is
>> not about what a RL lawyer would say, this is about common sense
>> and people being pissed off till they vomit and want to run away
>> screaming from SL, or at least from Linden Lab.
>>
>> On Sat, Aug 28, 2010 at 11:51:03AM -0400, Joel Foner wrote:
>> > Quick note... if the $100 a month, if this is rent, is not being paid to
>> > Linden
>> > Lab if you're renting. It's paid to another avatar... different
>> > picture... It
>> > seems to me the slap in the face is a landlord who does this to a large
>> > number
>> > of tenants without notice, actually.
>> >
>> > Joel (also going back to lurking)
>> >
>> > On Sat, Aug 28, 2010 at 11:42 AM, Darmath  wrote:
>> >
>> >      On 29/08/2010 1:23 AM, Gareth Nelson wrote:
>> >     >   and pointing out that LL have no contract with tenants of
>> >     > rental regions - tenants of such regions are thus not customers.
>> >     True. But a premium account holder is a customer of LL. "And to say
>> > well
>> >     we dont want you $100 a month because your not a full sim owner" is
>> > a
>> >     slap in the face, period. FWIW i'm a premium account holder...whose
>> > now
>> >     returning to lurking.
>> >     ___
>> >     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
>>
>>
>> --
>> Carlo Wood 
>> ___
>> 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
>
___
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] This is how Linden Lab treats it's customers...

[Marc Adored]

You guys do realize that linden gives you plenty of warnings and time
AFTER payment is due to "update" your payment information if you do so
happen to forget or a cc expires. it's not like its due on 13th and
bam its off on 13th. You get emails telling you payment failed(a few
of them actually) and the emails even contain information about
whether it was expired or just plain failed. I know because I use a 1
time payment card every month and I forget every month to put a new
card number in and guess what I even ignored the emails for days after
payment was due. Here is an experp:

"Don't worry; this billing failure will not prevent you from logging
on with your Second Life account.  We will simply try to bill your
overdue balance again the next day.  If we are unable to collect the
amount due within seven (7) days, your account will be suspended
pending payment for an additional thirty (30) days.  During that time,
you will not be able to log in to Second Life. Alt accounts may be
placed into administrative hold and you may be logged out of active
sessions during this time as well. Failure to resolve this billing
issue by the end of the probation period may result in the
cancellation of your account."

If you check your email less then 1 time every 37 days I don't even
know why you have a premium account on a game you obviously don't play
enough to get your monies worth.

Now all this being said Not only has this off-topic thread gotten off
of its own topic I believe a few of us on a few occasions asked for
this to be moved to a more appropriate forum. It clouds the actual on
topic discussions of this particular list and has nothing to do with
it. So please do so. We're all adults and everyone keeping this going
should understand this simple concept.

On Sun, Aug 29, 2010 at 5:24 AM, Marine Kelley  wrote:
> At least the land and inventory are not gone, automatically downgrading to
> basic would make the lands be abandoned... way to even more drama. To me the
> user should not even be locked out of the grid, but I understand that there
> are technical difficulties to making a premium be considered as basic until
> the funds are available again, and let's not forget that if you are premium
> and in this situation, then you do owe LL money. This is different than
> being simply basic.
>
> The only issue is that the user is ALSO locked out of their SL webpage. To
> me that makes no sense at all, because that's how they could access tickets
> and get some help, or downgrade to basic, or change credit card info (what
> if the original credit card has been stolen and the user blocked it ? That's
> not valid grounds to lock them out of SL and yet they can't change their
> credit card info through the SL webpage anymore). Locking them out of the SL
> website simply discourages them from even trying to sort things out, and LL
> loses money in the process.
>
>
___
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] Blocking viewers.

[Marc Adored]

Just switch to Phoenix its the projects new structure and project name.

On another not they have every right to police who and what is
connecting to their service. They also have every right to ban you for
whatever reason they want without giving any reason at all. They are
not policing your computer you have the choice to use other grids with
your banned viewer they are not blocking you from using the
application all together just blocking you from connecting to their
service with it.

On Wed, Sep 8, 2010 at 5:42 PM, Aleric Inglewood
 wrote:
> I'm not happy to say it, but I can't help myself...
>
> I told you so
>
> When LL announced the TPV list, it was already clear to me
> that they want to control what viewer can connect and that
> this was the beginning of whitelist. Soon every viewer that
> is not derived from their holy "2.0" will be blocked.
>
> On Wed, Sep 8, 2010 at 11:39 PM, Tom Grimshaw  wrote:
>>  Dear Linden Lab,
>>
>> It's absolutely none of your business what software I choose to run on
>> my PC.
>>
>> Blocking emerald is a step of pure arrogance - and ignorance - on Linden
>> Lab's behalf - it's not having an adverse effect on your servers, in
>> fact THE ONLY WAY you can tell i'm runing Emerald is by the channel and
>> version provided in login, and this has been proven by the number of
>> clones that have popped up with their channel renamed (and the ID
>> texture changed of course). You cannot censor Open Source software, and
>> the fact that you're trying to makes you a despicable organisation.
>>
>> Stop policing my computer. I will decide what viewer I use, thank you.
>>
>> ~T
>> ___
>> 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
___
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] Blocking viewers.

[Marc Adored]

Sorry but it is their service and they do have that right. They can
block you personally if they wanted to because they are providing you
with a service and they don't have to. Most people forget that. They
don't actually need any reason at all to stop providing you with
service. If they chose to block certain viewers because they want to
force people to use approved viewers then they have that right. I am
not talking about what they should do I am talking about what they
have the right to do. Honestly if they wanted to they could block any
non-official viewer and require everyone use their viewer. its just
like any service it is up to them on what they feel is beneficial to
the service. As i said previously they are not preventing you from
using that viewer they are just preventing you from using that viewer
on THEIR service is all. There are tons of more open grids you can
chose from to use your viewer if you chose too. I think most people
are spoiled by the fact that they have been given a choice by linden
labs. But thats how humanity works you give a little they want more
because they always devalue what they have.

Emerald is a perfect example of that. Everyone is upset and mad at
linden for banning Emerald but no body cared what the developers of
Emerald were doing before it effected them directly. I wont go into a
flame war over one of my favorite viewers but I just wanted to make
that point.

On Wed, Sep 8, 2010 at 5:49 PM, Tom Grimshaw  wrote:
>  On 08/09/2010 22:46, Marc Adored wrote:
>>
>> On another not they have every right to police who and what is
>> connecting to their service
>
> No, given that the data that the viewer is sending is identical, they have
> no right to do that whatsoever.  The software I choose to use on my PC is
> entirely my choice.
>
> I'll continue to use my own viewer that i've forked from Emerald a while
> back - this change doesn't affect me - but it does reflect extremely poorly
> on the lab and their ethics.
>
> ~T
>
>
___
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] Blocking viewers.

[Marc Adored]

I agree and Phoenix seems to be coming only very well to and all the
negativity behind emerald seems to be gone in the atmosphere of
phoenix. I am pretty excited to see where it heads! Maybe this thread
can be saved and put back on topic :D

Tom I know your upset about them banning Emerald but it was in their
right to do so there is no arguing that. I suggest that if you like
emerald you should try phoenix it is the cleaned up spawn of emerald
and has all the non-controversial developers from emerald working on
it even LGG :D I am sure you will notices differences in the viewer
but it has all the same features plus some really neat new ones.

On-topic part is phoenix is shaping up to be a pretty decently
organized opensource viewer should we focus on that now? :D

On Wed, Sep 8, 2010 at 6:04 PM, Altair Sythos  wrote:
> On Wed, 8 Sep 2010 17:59:41 -0400
> Marc Adored  wrote:
>
>> Emerald is a perfect example of that. Everyone is upset and mad at
>> linden for banning Emerald but no body cared what the developers of
>> Emerald were doing before it effected them directly. I wont go into a
>> flame war over one of my favorite viewers but I just wanted to make
>> that point.
>
> Emerald have good reason to be blacklisted, there is the "next step"
> called phoenix, cleaned by "bad code" and "bad elements", all other is
> only a lil actors show...
> ___
> 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] Blocking viewers.

[Marc Adored]

> Okay, let's just outline this properly.
>
> The lab DO NOT have any right to determine what software they will allow
> to connect to their SERVICE.  The only thing they DO have a right to do
> is to determine which TCP connections they want to accept and which UDP
> packets they want to accept.

And if they chose to determine what packets they wish to accept by the
viewer you are using it is there right. Just like that could by al
rights say only Windows users are allowed to use their service. It is
THEIR right to chose and YOUR privilage to use their service.

> It's my right to use whichever software I
> want to generate those packets. As such, I accept that they have the
> legal right to block logins from clients containing "Emerald" in their
> version string - but not a moral right. And they certainly do not have a
> right to threaten people with account bans if they "bypass" the ban.
>

They actually do have EVERY right to threaten people with account bans
if they do not follow the terms of service or try to bypass any
quality control measures they take.

> Linden Lab have blocked Emerald due to a POLITICAL DISAGREEMENT with
> their dev team.  They haven't blocked it because of any fault with the
> software itself,  they're not protecting anyone - they're taking
> pre-emptive action against a project because of some percieved danger
> that might evolve.

You may be right about its current state but a few times in the past
it it has proven to be unsafe for secondlifes user base to use it and
the dev team that was on it could not be trusted to not allow those
things to happen again. But this is going into the REASON why the
banned it which is irrelevant to the fact that they DID ban it. Like I
said regardless of the "morals" behind it they have every right to ban
whatever for whatever they want it is their service. Legally they have
obligations to their user base. Normally this wouldn't apply to third
party products but they did set a standard for third party products so
they have to uphold that standard or they me be legally obligated for
any damage a third party application they endorse may cause.
___
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] User Story: Improved Cache

[Marc Adored]

I think that maybe "places" should have scores of how often they are
visted to determine how long the cache of that place is stored. So
since every login you start at home it would have a high score
therefore the cache would be stored for a longer period of time. Same
goes for places you visit often. This would remove any interaction
needed by the user because the system would pretty much auto detect
what places you would have as a favorite...

On Thu, Sep 16, 2010 at 12:58 PM, Kelly Linden  wrote:
> Strictly speaking I think you have the stories and tasks reversed here.
>
> As a user I'd like to be able to use a greater portion of my available disk
> to improve the SL experience.
> * Task: Improve the cache system to allow larger caches
>
> As a user I'd like the places I visit most often, like my 'home' and
> favorites, to load more quickly
> * Task: Improve the cache system to not discard data for my home (at least
> not for a while)
> * Task: Improve the cache system to not discard data for my 'favorites'
> places (at least not for a while)
>
> As a user I'd like to never have to clear the cache to fix a bug
> * Task: Implement a quick and efficient inventory verification to find
> inventory cache discrepancies.
> * Task: (Are there other common bugs that require a cache clear to fix?)
>
> Improving the cache system is a task (actually multiple tasks) used to
> accomplish the three experience stories you have. Stories should generally
> be about the end experience, not the underlying system or how the
> experiences will be fixed. Yes, that is a rough guide, especially for many
> stories where the actor is 'a developer', but it helps still. :)
>
> That said these are great ideas, and should definitely be on a backlog
> somewhere if they aren't. I know we have discussed all of them at one point
> or another.
>
>  - Kelly
>
> On Thu, Sep 16, 2010 at 9:44 AM, Daniel  wrote:
>>
>>  As a user I would like to see an improved cache in order to have a
>> better Second Life experience.  The types
>> of improvements that would lead to a better experience include:
>>
>> * A higher cache size limit.  This would let me save more data and speed
>> up rez times, and also put less
>> load on the server side, since it would not have to refresh discarded
>> data as often.  Modern hard drives
>> are much much larger than the current 1 GB limit, and I should be able
>> to allocate more storage to
>> my Second Life data if it improves performance.
>>
>> * Ability to set certain locations as "home" or "favorites", and to
>> never discard or preferentially keep those
>> locations in cache.  Places I know I will visit often should not be
>> discarded just because I happen to visit
>> several other locations in the course of a session.
>>
>> * More reliability in cache storage, leading to less often need to
>> delete cache to fix a problem caused by
>> cache corruption.  A low level inventory verification (meaning it does
>> not take a large percentage of viewer
>> resources) to ensure it matches the asset database is an example, but
>> technical implementation I will leave
>> to programmers.  The desired result is less frequent issues like
>> apparent inventory loss, which upsets users
>> and leads to support tickets.
>> ___
>> 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
>
___
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

[opensource-dev] Option to send notices to email even when online

[Marc Adored]

I wasn't sure if this is the right place to post this but on the
https://lists.secondlife.com/cgi-bin/mailman/listinfo page it says
sldev has been moved here so i suppose this is the only place to post
this.

I posted a jira for this option because I couldn't find an existing
jira and just wanted to get the word out about it and see others
opinions on it. I know there are other people who at one point and
time needed a past notice to review past events to make better
decisions on current events and didn't have in in their email because
they where online when the notice was sent out. Specially in large
groups with lots of RP action and disciplinary notices.

The jira is at:
http://jira.secondlife.com/browse/SVC-6330
___
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] Lindens way ahead of us

[Marc Adored]

RLV is usually optional when its added to other viewers and can often times
be very useful to hud makers. I have a hud now I made for myself that force
tp's to bookmarked places I have set in the hud. There are other uses for it
besides all the dirty possessive stuff it was originally intended to be for
:P

On Sun, Sep 26, 2010 at 10:56 PM, Erin Mallory  wrote:

>  Yay for breast physics, but PLEASE PLEASE PLEASE say that RLV is NOT being
> added
> RLV is just scary and I will look for a tvp without it before I allow
> others to take my clothes off with an RLV trap...
>
> --
> Date: Sun, 26 Sep 2010 19:37:30 -0700
> From: miss_c...@yahoo.com
> To: opensource-dev@lists.secondlife.com
> Subject: [opensource-dev] Lindens way ahead of us
>
>
> All this talk about adding these plug ins RLV and breast physics plug
> ins were added to viewer 2 already.
>
> They were just going to surprise us I suppose -.-
>
> I found it here
> http://bitbucket.org/oz_linden/test1/changeset/bbecf41db5c8
>
> Quote:
> merge avatar physics up to latest viewer-development
>
> 49 
> 
>
> #include "llbreastmotion.h"
>
>  49 
> 
>
> 50 
> 
>
> #include "llviewercontrol.h"
>
>
>
>
> YAY
>
> Miss
>
>
> ___ Policies and (un)subscribe
> information available here: 
> http://wiki.secondlife.com/wiki/OpenSource-DevPlease 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
>
___
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] Lindens way ahead of us

[Marc Adored]

Actually there is no way to turn it on in other peoples viewers if its
in their viewer. If someone told you that they mislead you. The on/off
is whatever you set it too, no body else can change that short of
hacking your computer. There is no backend or hidden code or anything
like that. I have yet to see a TPV that has any such feature.

RLV adds a lot of useful features scripters can take advantage of just
like I mentioned previously like force sitting and force teliporting
can be great for automating things like rides and tours or even huds
for combat that can send you to other parts of a sim or detach weapons
or really anything you can imagine. Please be careful repeating things
you've herd false information can be very damaging and hinder very
good progress. Personally I would rather see RLV over breast physics
but then again thats just me :P

On Sun, Sep 26, 2010 at 11:30 PM, Erin Mallory
 wrote:
> yeah, I've had it on by default in a couple viewers i tried, and in one of
> those it claimed to be off.  and there's ways to turn it on other people's
> viewers without them even knowing.  I do not understand why LL would include
> RLV into a viewer.
>
> 
> Date: Sun, 26 Sep 2010 21:00:14 -0600
> Subject: Re: [opensource-dev] Lindens way ahead of us
> From: ilana.debe...@gmail.com
> To: angel_of_crim...@hotmail.com
>
> Don't panic. If you don't turn RLV on or you don't wear an RLV relay it
> absolutely CAN NOT affect you
> On Sep 26, 2010 8:56 PM, "Erin Mallory" 
> wrote:
>>
>> Yay for breast physics, but PLEASE PLEASE PLEASE say that RLV is NOT being
>> added
>> RLV is just scary and I will look for a tvp without it before I allow
>> others to take my clothes off with an RLV trap...
>>
>> Date: Sun, 26 Sep 2010 19:37:30 -0700
>> From: miss_c...@yahoo.com
>> To: opensource-dev@lists.secondlife.com
>> Subject: [opensource-dev] Lindens way ahead of us
>>
>>
>>
>> All this talk about adding these plug ins RLV and breast physics plug
>> ins were added to viewer 2 already.
>>
>> They were just going to surprise us I suppose -.-
>>
>> I found it here
>> http://bitbucket.org/oz_linden/test1/changeset/bbecf41db5c8
>>
>> Quote:
>> merge avatar physics up to latest viewer-development
>> 49
>> #include "llbreastmotion.h"
>>
>>
>>
>>
>>
>> 49
>> 50
>> #include "llviewercontrol.h"
>>
>>
>> YAY
>>
>> Miss
>>
>>
>>
>>
>>
>> ___
>> 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
>
___
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] Lindens way ahead of us

[Marc Adored]

Well as I said before off is off and on is on your choice. Much more
choice then breast physics give. I find it creepy that some perv is
looking at my wife watching her boobs bounce and she has no control
over it other then logging off which is unacceptable btw. Not that it
really bothers me but I'm just sayin... At least with RLV features
they are controllable by the person that matters which is the person
it controls. I was trying to stay away from the whole creepy thing
because it is the more subjective issue of this thread and tried to
focus on the usefulness of the features. Regardless of what the fact
that you can see the usefulness of it I do and others have based on
the features I see added into some very popular huds like the emdash
hud which has a "favorites" landmark feature which when you set it to
can automatically teliport to to locations instead of giving you map
links which you have to click then click again to teliport or it can
force you to sit on a teliporter to go to the spot if its in the same
sim instead of you having to click on the teliport to sit yourself.
This is something you have to eneable even if RLV is enabled its not
something that happens automatically. Also most RLV implementations
have a warning when scripts try to use it the first time until you
allow it for security reason. After all it would really suck to attach
a hud that stripped you naked and tp'd you to sex sim :P Again the
emdash features may not be something you may find useful but I do
saves a lot of time and aggravation and just makes the tool seem that
much better integrated. The only usefulness I can see for breast
physics is having my wife do the bay watch gesture and we enjoy her
boobs bouncing for a good minute as a novelty. Some people have
control issues which make the useful features of RLV scary or even
creepy and those people shouldn't use it which is why there is on and
off switches :)

I see possibilities for misuse but only to people who are click happy
and don't read warnings when they come up. other then that a script
will only have control of your RLV features if you allow it to and RLV
will only have control of you if you allow it to. A simple relog and a
few clicks and RLV is off if something goes wrong no big deal. So to
me i see much more gain and very little potential for abuse.

I'll stop replying now though because I have said all I need to say at
least I think and the next step is just to become a flame war which is
not productive.

On Sun, Sep 26, 2010 at 11:48 PM, Erin Mallory
 wrote:
> "RLV adds a lot of useful features scripters can take advantage of just
> like I mentioned previously like force sitting and force teliporting
> can be great for automating things like rides and tours or even huds
> for combat that can send you to other parts of a sim or detach weapons
> or really anything you can imagine."
>
> That's just creepy. I cannot think of a single legitimate reason I would
> need to be force teleported anywhere except possibly by a linden.
> Linden teleports were already built into the viewer.  Why would I need or
> want a combat system to disarm me or teleport me?
> If a combat hud could disarm me, then so could someone that made a hacked
> hud to cheat with. And whose to say it would stop with weapons?
> Sorry, I see way too much potential for abuse and not enough for gains.
> there are already systems in place for tours with teleportation systems that
> don't need rlv scripts to work.
>
>
>> Date: Sun, 26 Sep 2010 23:37:07 -0400
>> Subject: Re: [opensource-dev] Lindens way ahead of us
>> From: m...@inworlddesigns.com
>> To: angel_of_crim...@hotmail.com
>> CC: opensource-dev@lists.secondlife.com
>>
>> Actually there is no way to turn it on in other peoples viewers if its
>> in their viewer. If someone told you that they mislead you. The on/off
>> is whatever you set it too, no body else can change that short of
>> hacking your computer. There is no backend or hidden code or anything
>> like that. I have yet to see a TPV that has any such feature.
>>
>> RLV adds a lot of useful features scripters can take advantage of just
>> like I mentioned previously like force sitting and force teliporting
>> can be great for automating things like rides and tours or even huds
>> for combat that can send you to other parts of a sim or detach weapons
>> or really anything you can imagine. Please be careful repeating things
>> you've herd false information can be very damaging and hinder very
>> good progress. Personally I would rather see RLV over breast physics
>> but then again thats just me :P
>>
>> On Sun, Sep 26, 2010 at 11:30 PM, Erin Mallory
>>  wrote:
>> > yeah, I've had it on by default in a couple viewers i tried, and in one
>> > of
>> > those it claimed to be off.  and there's ways to turn it on other
>> > people's
>> > viewers without them even knowing.  I do not understand why LL would
>> > include
>> > RLV into a viewer.
>> >
>> > 
>> > Date: 

Re: [opensource-dev] O.O Display name code DROP!

[Marc Adored]

All this panic did anyone stop to think that maybe this is part of a
bigger plan? The first thing that cam to mind for me was maybe it
makes it easier for programs to format them and probably better for
searching and stuff (withen a program). Also maybe there are plans for
a built in log viewer coming soon? I think that this format is less
then ideal but then again I have no idea what might be planned and why
this specific format was chosen

On Fri, Oct 15, 2010 at 4:46 PM, Garmin Kawaguichi
 wrote:
> It was a JIRA from Samia Bechir
> https://jira.secondlife.com/browse/VWR-22940 dated from September 10
> You can vote for it
>
> GCI
>
>
>
> - Original Message -
> From: WolfPup Lowenhar
> To: OpenSource Mailing List
> Sent: Friday, October 15, 2010 2:58 AM
> Subject: [opensource-dev] O.O Display name code DROP!
>
> Well folks my night is going to be interesting as now I have to hard merge
> my logging code to the new code as there are changes to the way logs are
> EVEN saved .llsd instead of .txt which is going to make things interesting
> for me as now I have to change my history look up code for the new file
> extension and maybe even the name formatting itself!
>
> 
>
> ___
> 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
>
___
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] O.O Display name code DROP!

[Marc Adored]

Download a stylesheet? The file would contain a link directly to the
stylesheet and would be automatically loaded. Also I'm not sure about
your operating system but I'm pretty sure the file extension already
opens in your default browser and once the stylesheet is specified it
will look just like a plain text log file just loaded in your browser
through the same process and opening a text file. The only fear here
is change and the unknown. It's not going to be any harder to read the
logs just different. Sorry like Ricky said its more future proof and
thats all there is too it the only mistake was not setting this up
earlier so the change didn't frighten so many people

On Fri, Oct 15, 2010 at 6:31 PM, Erin Mallory
 wrote:
> Actually its a bad move.  For one: logs should NOT have fields.  The display
> name used at the time should NOT change in the logs once someone changes
> their user name, which appears to be what this file format does.
> TWO, to require you users to download a style sheet and use a web browser to
> view logs is just asininely retarded.  Users who need their logs regularly
> need to access them FAST and in an EASY format to read and print.
> This is another case where LL took a good idea and implemented it so badly
> as to make it a total fail.   This really needs to be undone.
>
>> From: kf6...@gmail.com
>> Date: Fri, 15 Oct 2010 15:23:49 -0700
>> To: labrat...@gmail.com
>> CC: opensource-dev@lists.secondlife.com
>> Subject: Re: [opensource-dev] O.O Display name code DROP!
>>
>> Actually, IMHO that was the catalyst, not the reason. The reason was
>> that there needs to be a pile of information about the posts. The log
>> files just don't contain enough information, especially with Display
>> Names. With an expanded format, such as any of LLSD/XML/JSON, you can
>> associate all the needed information in an expandable, fairly
>> future-proof format. Text files just don't cut it. Named fields, as
>> given by any of the above formats, allow adding fields without
>> breaking any tools made for the new format. Text doesn't. Neither any
>> of the common flavors of CSV. It's just sad that the files weren't in
>> one of these formats a long time ago. Something I'm going to take to
>> heart as I develop games and tools.
>>
>> Now, as to LLSD over any of the others. The reason is ease of coding.
>> LLSD is something already used, and fairly well-defined, in the
>> viewer. A custom XML or JSON format would take defining the syntax,
>> creating a standard, etc. LLSD is already there, and well known. The
>> functions for converting to it are all already in place. As such it's
>> less bloat to the viewer to use that format. In fact, depending on
>> how the structure exists in the code (I haven't looked,) it may have
>> even been easier to export as LLSD than the original text.
>>
>> Adding an option WOULD have been bloat. if you want text in the
>> original style, JSON, Wikicode, or prettified HTML, all it takes is
>> running the log file though the proper XSL stylesheet using your
>> favorite XML processing tool. Pretty trivial. Such tools could even
>> be built into the viewer, but I don't see the need. Those who do,
>> feel free to add to a TPV, or provide a solid, reasoned argument for
>> such. Or you can get it added to a TPV, if the author finds it useful
>> to them.
>>
>> Over-all I think this was a good move: the files are easier to write
>> lexers for as we can leverage existing parsers, and they are still not
>> too hard to read from a human standpoint - assuming useful line breaks
>> in the files.
>>
>> Ricky
>> Cron Stardust
>>
>>
>> On Fri, Oct 15, 2010 at 2:52 PM, Harold Brown  wrote:
>> > This is another change that a very small percentage of people wanted
>> > that was made without consideration to how it affects the larger
>> > community.
>> >
>> > The PROPER change should have been to add an OPTION to log to .llsd
>> > for those people making log files of Office Hours parsing log files
>> > for posting to the wiki was the reason for this change.
>> >
>> > On Fri, Oct 15, 2010 at 2:36 PM, Ricky  wrote:
>> >> Besides, back on Sept 2nd this was already discussed, and plans
>> >> invented.
>> >>  https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003162.html
>> >>
>> >> All that's needed is a linked XSL stylesheet to make it just as easy
>> >> to read as the text files were.  Just using a web browser instead of a
>> >> text editor.  Josh s

Re: [opensource-dev] O.O Display name code DROP!

[Marc Adored]

Which part is bullocks? The accurate description of how things will
change or the accurate description of how things will change? Fact is
it's not going to change much for anyone when its finished (assuming
they are going to provide a stylesheet for it). You will still simply
double click the file to open it and view the log and you can search
the same way you did before with ctrl+f or whatever your os's normal
search keys are. nothing changes but the program it opens in. If for
some reason it is not associated with your browser simply double
clicking the file will ask you what to open it with and you just tell
it to remember that and your back to normal.

So as I see it no disadvantage outside of a slightly larger file size.
But a big advantage on the other side. Its a easier format to "parse"
which will allow you to see it and search it easier and faster in
whatever program that is made to parse the files either built into the
viewer or an external log management system.

Above all that a change like this had to happen. There was no way
around it. With Display names being variables now it had to happen.
They had to have a way to link the variable to the constant... This to
them and the more i read to me seemed like the best solution. Its
already a built in format the viewer already uses and is very
extensible when it comes to adding/removing things and styling.
Essentially if they load a local stylesheet that would allow you to
modify the stylesheet to make your logs look the way you want them
like changing a theme. I'm sure this idea will be used for an internal
log viewer if its added.

All I am really saying is wait for it. It is beta and doesn't seemed
to be finished yet. To people who know what is capable with the format
know what might be planned. I know for someone who doesn't know about
the format or anything outside of plaintext it might be garbage right
now but the potential is huge

On Fri, Oct 15, 2010 at 6:44 PM, Dave Booth  wrote:
>  On 10/15/2010 17:38, Marc Adored wrote:
>
> 
>
> Bollocks.
> ___
> 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] O.O Display name code DROP!

[Marc Adored]

Oh well so much for progress :( Is linden labs going to provide a tool
to convert current llsd logs back to plaintext?

On Fri, Oct 15, 2010 at 7:23 PM, Leyla Linden  wrote:
> Hi All,
> The chat log format change wasinitially done so we could easily add
> more information in the chat logs.  Now that the display name can
> change it's nice to have more data like an agent_id that can be hooked
> up to inspectors.
> But seeing as how many people rely on easily readable text chat logs,
> we're going to revert them back to text files.  The only difference is that
> they'll include both display names and usernames, much like Rob
> Nelson suggested.
> - Leyla
> ___
> 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] Replying to OpenSource-Dev using Gmail.

[Marc Adored]

Use reply to all it replies to the person ad cc's to the mailing list.
Somehow the person in the TO field doesnt get a duplicate either like
you think they would so it works perfect.

On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville
 wrote:
> I switched my listmanager settings from Digest to individual messages
> recently.
>
> I use Gmail.
>
> I just tried to reply to an OSD thread, and it appears that the mail would
> be going to one individual rather than to the mailing list.
>
> I didn't seem to have this problem with the list set to send digests,
> however then the mail is filled with repeatedly quoted text.
>
> Also with the list sent to not use digest mode, the From field in Gmail
> shows an individual's name rather than Open Source Dev Request like it does
> when the list is in digest mode.
>
> Anyone know how to make Gmail do a little better with this list?
>
> --
> v i r t u a l   w o r l d   e n t h u s i a s t
> -- http://www.google.com/profiles/s u e z a n n e --
>
> ___
> 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] Replying to OpenSource-Dev using Gmail.

[Marc Adored]

The problem is the list sends the email to you from the sender not
from the list so gmail replies to the person because reply replies to
the sender. My other lists don't have this issue so I'm pretty sure
its a setting set differently in mailman that linden might should
change to make replying act like you think it would. I see a lot of
replies to emails that never hit the list but the sender never knew
because they just hit reply. Countless times have I seen people say "I
think this was relavant to the whole list" and forwarding it to the
list so people can see. I guarantee you the person who sent them the
email thought it was going to the whole list.

On Fri, Oct 15, 2010 at 7:49 PM, SuezanneC Baskerville
 wrote:
> Thanks.
>
> Gee, it would be nice if it would work like it looks like it would work.
>
>
>
> On Fri, Oct 15, 2010 at 6:39 PM, Teravus Ovares  wrote:
>>
>> On that note, there's a gmail Lab feature which makes 'Reply to All'
>> default and makes it so you have to dig for 'Reply' when you want to reply
>> to someone individually off list. I use it for this e-mail address..
>> but be careful.   It might not be appropriate for every situation.
>>
>> -Teravus
>>
>> On Fri, Oct 15, 2010 at 7:21 PM, SuezanneC Baskerville
>>  wrote:
>>>
>>> I switched my listmanager settings from Digest to individual messages
>>> recently.
>>>
>>> I use Gmail.
>>>
>>> I just tried to reply to an OSD thread, and it appears that the mail
>>> would be going to one individual rather than to the mailing list.
>>>
>>> I didn't seem to have this problem with the list set to send digests,
>>> however then the mail is filled with repeatedly quoted text.
>>>
>>> Also with the list sent to not use digest mode, the From field in Gmail
>>> shows an individual's name rather than Open Source Dev Request like it does
>>> when the list is in digest mode.
>>>
>>> Anyone know how to make Gmail do a little better with this list?
>>>
>>> --
>>> v i r t u a l   w o r l d   e n t h u s i a s t
>>> -- http://www.google.com/profiles/s u e z a n n e --
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> v i r t u a l   w o r l d   e n t h u s i a s t
> -- http://www.google.com/profiles/s u e z a n n e --
>
> ___
> 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] O.O Display name code DROP!

[Marc Adored]

>
> Let's see...  Future Proof.
>
> Program to read and process a text file - anywhere from a few hundred
> bytes, to a small OS-wannabe like emacs.  Program to process LLSD and
> display it - several hundred K minimum, oh, and *REQUIRED* network
> connection live so the referenced DTD can be retrieved -

And why would a network connection be required for a local DTD? also
why else would you need to look at a log unless it was for something
you where doing online? So even IF it was a remote DTD it wouldn't
matter. Who here disconnects their internet to look at logs? What
paranoia provokes that?

> more like a
> program that is ALREADY being considered an OS-replacement, such as
> Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes.
>

Well you can exaggerate the problem all you want but most applications
now run in a browser anyways and more then likely they will have their
browser already open whether its posting logs to a blog or to the wiki
or responding to a forum post guess what the browser is already open
hmm don't see a problem

> Ok, so let's look at a project that's *GOT* a nice long history already
> (some 30+ years) and is *VERY* interested in future-proofing.  Minor
> project, really, called Project Gutenberg.  Here's what *they* have to
> say on the subject:
> http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F
>
> When you really, really, *REALLY* want it to be readable - ASCII
> plaintext is the way to go.

It's not really about readable its about future proofing and linking a
variable name with a constant name and adding features that some may
find useful. Like I said most probably wont even notice the change and
some will probably even like the fact that it opens in a program
probably already open.

Anyways all of this means nothing anymore because all of the
complaining made them reverse it so none of it matters anymore but I
felt the need to respond because once again someone took what was
wrote made assumptions(incorrect ones at that) about what was said and
responded.

I understand the reasons people are mad I hate change too. The only
difference is I don't instantly discount change and start fighting
against it. Its the same as when I talk to someone and I say something
about viewer 2 and they say "oh I don't like viewer 2". I ask why and
they say "oh I used it for about 2 seconds and switched back" that
comment alone completely discredits anything else that comes out of
that persons mouth about the viewer. They have no right speaking
anything about it when they didn't give it a fair chance. Just like
this change it didn't even get finished yet before people went nuts
about it.


I suppose using log formats like this:

[44/44/ 10:10:10] Display Name(real.name): something here

will be fine for reading.
___
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

[opensource-dev] Fwd: O.O Display name code DROP!

[Marc Adored]

Woops forgot to reply to all so it went to the list :P


I think your post here:

https://lists.secondlife.com/pipermail/opensource-dev/2010-September/003167.html

Was a very good one explaining what the advantages could be. A true
xml format like that would be easy to read and easy to parse. Of
course its not a line by line conversation like you read in the viewer
but it is in an order and all information would be provided in an easy
to read format provided the viewer exports the xml with proper line
endings and tab spacing :P

Did a jira ever get posted about that?

On Fri, Oct 15, 2010 at 8:32 PM, Ricky  wrote:
> I'd have to say that future proof and archival safe are two separate
> qualities.  Logs might need to be archived, but 90% (guessing) of the
> content is fluff only useful for a couple of months to a year at the
> most.  However, the tools that read them (such as converters /
> archivers) have a much longer lifespan.  If you do want 50+ year
> archival quality, then use a trivial exporter to convert to the ASCII
> format of your choice when you run your archival process and send it
> to paper punch tape.  (I'm not being insulting here: paper punch tape
> is THE most long-lived digital format I've ever met.)
>
> As to the stylesheet: I propose that it be installed with the viewer
> and be located in the same folder as the logs.  This way it can be
> archived along with the files by your favorite archival/storage tools.
>
> And viewing the file is likewise not an issue.  Every modern computer
> already has a browser installed and in use.  And if you still needed
> to read the log from a GUI-less computer, the logs are still ASCII.
> The tags surrounding the data are just helpful to the computer.  This
> isn't a binary format we are discussing; it's a formatted text file.
> Formatted in a way that makes it easier for a computer to read while
> still being useful to the humans involved.
>
> On Fri, Oct 15, 2010 at 5:11 PM, Jamey Fletcher  wrote:
>> Marc Adored wrote:
>>
>>> Download a stylesheet? The file would contain a link directly to the
>>> stylesheet and would be automatically loaded. Also I'm not sure about
>>> your operating system but I'm pretty sure the file extension already
>>> opens in your default browser and once the stylesheet is specified it
>>> will look just like a plain text log file just loaded in your browser
>>> through the same process and opening a text file. The only fear here
>>> is change and the unknown. It's not going to be any harder to read the
>>> logs just different. Sorry like Ricky said its more future proof and
>>> thats all there is too it the only mistake was not setting this up
>>> earlier so the change didn't frighten so many people
>>
>> Let's see...  Future Proof.
>>
>> Program to read and process a text file - anywhere from a few hundred
>> bytes, to a small OS-wannabe like emacs.  Program to process LLSD and
>> display it - several hundred K minimum, oh, and *REQUIRED* network
>> connection live so the referenced DTD can be retrieved - more like a
>> program that is ALREADY being considered an OS-replacement, such as
>> Internet Explorer, Mozilla, Safari, or Chrome, each several dozen megabytes.
>>
>> Ok, so let's look at a project that's *GOT* a nice long history already
>> (some 30+ years) and is *VERY* interested in future-proofing.  Minor
>> project, really, called Project Gutenberg.  Here's what *they* have to
>> say on the subject:
>> http://www.gutenberg.org/wiki/Gutenberg:General_FAQ#G.17._Why_is_Project_Gutenberg_so_set_on_using_Plain_Vanilla_ASCII.3F
>>
>> When you really, really, *REALLY* want it to be readable - ASCII
>> plaintext is the way to go.
>> ___
>> 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
>
___
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

[opensource-dev] Viewer 2 beta crash osx

[Marc Adored]

Ok so I have been having the crashing problem on login every since
viewer 2. I can still login fine with the viewer 1.x viewers but none
of the viewer 2 viewers login fully they just crash. I have tried
clearing cache and deleting everything blah blah even reinstalled osx
and same thing. Here is a video of when it crashes

http://www.youtube.com/watch?v=nw9I1W6ugvI

What else can I provide to help figure out what it might be?
___
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] Viewer 2 beta crash osx

[Marc Adored]

Well I think I just narrowed it down. I turned off streaming media and
I am able to login now. I guess viewer 2 auto loads the media even if
it isn't set to auto play? I should have thought of it earlier and I
don't know why I didn't. I can't play streaming media in the v1.x
viewers either but they don't try to play the streams auto or
something because I don't have to disable it on them I just can't play
them.

On Sat, Oct 16, 2010 at 2:11 AM, Erin Mallory
 wrote:
> I would attach that video, any logs you can collect, and possibly a screen
> of anything odd in your inventory to a jira.  I might also attach some logs
> of a successful login in with 1.x  I knwo the codebases are different, but
> theres always the slim hope that by comparing the two something might become
> obvious.  beyond that i dunno?
>
>> Date: Sat, 16 Oct 2010 01:10:50 -0400
>> From: m...@inworlddesigns.com
>> To: opensource-dev@lists.secondlife.com
>> Subject: [opensource-dev] Viewer 2 beta crash osx
>>
>> Ok so I have been having the crashing problem on login every since
>> viewer 2. I can still login fine with the viewer 1.x viewers but none
>> of the viewer 2 viewers login fully they just crash. I have tried
>> clearing cache and deleting everything blah blah even reinstalled osx
>> and same thing. Here is a video of when it crashes
>>
>> http://www.youtube.com/watch?v=nw9I1W6ugvI
>>
>> What else can I provide to help figure out what it might be?
>> ___
>> 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] O.O Display name code DROP!

[Marc Adored]

Lance check the jira if the file ext is changes to xml it will
automatically open in IE,Firefox,Chrome,Whatever Browser they have as
default and it will display styled to look just like the plain text
old versions only underneath it will contain much more information.
Those stylesheets can also be highly dynamic to include/exclude
whatever information about each line of log with javascript

On Sun, Oct 17, 2010 at 4:34 AM, Lance Corrimal
 wrote:
> Am Sonntag 17 Oktober 2010 schrieb Ricky:
>> I agree, the XML notation is far from perfect (see some of my posts
>> last year about the subject,) however I consider it better than
>> either text or this almost-JSON notation for a variety of reasons,
>> all laid out in https://jira.secondlife.com/browse/VWR-23451 for
>> ease of reference.
>>
>> Assuming that the order of fields is fixed, a fair assumption as
>> LLSD requires it I believe, then the XSLT isn't so bad, and a
>> prototype has already been made.
>>
>> On the subject of using other standard tools, such as
>> grep/sed/awk/etc., I fully agree.  This is why I'd fight against
>> any binary or compressed format.  However, no such proposal has
>> been made.
>
> Guys, keep one thing in mind:
>
> the average user has no inclination of "processing" the logfiles with
> anything.
>
> The average user, at best, will open the logfiles in notepad to look
> at them, and to find stuff like "what was the name of that place that
> i heard about at that or that date".
>
> The average user runs windows, where tools such as grep/awk/sed are
> not exactly common, either.
>
>
> bye,
> 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

Re: [opensource-dev] Fermi Viewer

[Marc Adored]

Yes that could be awesome like The Fermi Builders Mod for Phoenix or
better yet Kirstens :D


On Mon, Oct 18, 2010 at 1:54 AM, Francesco Rabbi  wrote:
> I think Carlo mean something else... In place to create another viewer
> join an existing team and contribute code for building and SIM
> managements
>
> --
> Sent by iPhone
>
> Il giorno 18/ott/2010, alle ore 03:02, "Arthur Fermi"
>  ha scritto:
>
>> Well LLs base is a decent start point.  We have looked at the other viewers
>> and think we have some good ideas.  I find that most of the other viewers
>> are not focused on building or sim management.
>>
>> -Original Message-
>> From: Carlo Wood [mailto:ca...@alinoe.com]
>> Sent: Sunday, October 17, 2010 7:59 PM
>> To: Arthur Fermi
>> Cc: opensource-dev@lists.secondlife.com
>> Subject: Re: [opensource-dev] Fermi Viewer
>>
>> Imho, it is not a good idea to start yet-another-viewer.
>> The number of open source coders are limited, they should
>> be working on one viewer - not twenty.
>>
>> We already have more than 10 different viewers based
>> on LL's code. How is it possible we need another?
>>
>> On Sun, Oct 17, 2010 at 06:09:49PM -0500, Arthur Fermi wrote:
>>> Fermi Sandbox is looking to put together a team to develop the Fermi
>> Viewer.
>>> Please send inquires to arthur_fe...@fermisandbox.org or in world.
>>>
>>>
>>>
>>> Mission
>>>
>>> The Fermi Viewer projects goals are to create the best viewers for Second
>> Life
>>> that works with all OS Grids.  The Fermi Viewer will be open for all to
>> review
>>> and look at, and all in house code will be generated and provided to the
>>> community.
>>>
>>>
>>>
>>> Project Overview
>>>
>>> The Fermi Viewer project will generate 2 separate viewers, one will be a
>> full
>>> featured viewer along the lines of emerald, this will be a general viewer
>> with
>>> a focus on building and sim management.  The second view will be as light
>>> weight and fast as can be made, it will have building and sim management
>> as its
>>> only focus with as many non-essential items moved out.
>>>
>>> Viewers will initial be based on the 1.x Snowglobe code from Linden Labs.
>> A
>>> Version 2 viewer will come later in the project when time and resources
>> are
>>> available to dedicate to a redesign of the interface.
>>>
>>>
>>>
>>> Open Source
>>>
>>> All work coming from the Fermi Viewer project will be returned to the
>>> community, this is a 100% open source project.
>>>
>>>
>>>
>>> Code Review
>>>
>>> All code other than the Linden Labs provide source code will be reviewed
>> by a
>>> peer review committee to ensure that it complies with privacy standards.
>> Once
>>> code is has been reviewed it will not need further review unless it has
>>> changed.
>>>
>>>
>>>
>>> Viewer Privacy Policy
>>>
>>> The Fermi Viewer will contain no code that will gather any information
>> other
>>> than is required for interoperation with the grid it is connected to.  No
>>> information will be stored off the client computer, no anonymous tracking
>> data
>>> will be collected.   Any violation of this policy will result in the
>> instant
>>> removal from the project.
>>>
>>>
>>>
>>> Arthur Fermi
>>>
>>>
>>>
>>
>>> ___
>>> 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
>>
>>
>> --
>> Carlo Wood 
>>
>>
>> ___
>> 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
>
___
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] (CTS-315) march choice for 64bit builds

[Marc Adored]

I assume that they probably used some SSE2 optimizations for the mesh code

On Fri, Oct 22, 2010 at 9:23 PM, Carlo Wood  wrote:
> Why is SSE2 required now? Sorry if I missed this.
>
> On Sat, Oct 23, 2010 at 03:08:26AM +0200, Boroondas Gupte wrote:
>> Because SSE2 is now required anyway, -march=pentium4 is now passed for 
>> building
>> lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. 
>> (See
>> CTS-315.) What should march be set to for 64bit buids, if anything?
>
> --
> Carlo Wood 
> ___
> 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] [Linux] Viewer crash with no meaningful error message when cache dir. is missing

[Marc Adored]

Maybe its crashing because it cant "create" the missing cache folder
because that mount point doesn't even exist not really because it cant
find it. It automatically creates it if it doesnt exist normally.
Either way a error message stating what happened would be very helpful
:P

On Sat, Oct 23, 2010 at 7:37 AM, Opensource Obscure  wrote:
> Short version: if the Linux viewer can't find the cache
> directory (even if empty), it will crash immediately,
> without providing any helpful error message.
>
> This happened to me after I moved the cache location
> to a secondary partition, and ran the viewer while the
> partition wasn't mounted.
>
> As a viewer user, I'd like to get a meaningful error
> message in such a situation.
>
>
> Opensource Obscure
>
> ___
> 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] Files deleted by uninstaller don't appear in Recycle Bin

[Marc Adored]

Wow such a big discussion. I think the best plan would be to have both
ways as an option like lots of installers do. Check this box to delete
all files program created after it was installed simple enough and
solves really any problem that arrises from left over cache and stuff
if one is trying to reinstall a viewer

On Thu, Oct 28, 2010 at 6:08 PM, Ponzu  wrote:
> I don't see this as a theoretical issue about whether the logs should be
> deleted, or not.  (Note the word "should".)
> Many users don't like it.  Don't do it.
> lee
> ___
> 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] What is the license status of UI sounds ?

[Marc Adored]

I've always wondered why the viewer had to download sounds that are
part of the UI. It makes more sense to have the UI sounds as part of
the skin. Would also make skins even more unique :)

On Mon, Nov 15, 2010 at 4:27 AM, Lance Corrimal
 wrote:
> Am Sonntag, 14. November 2010, 15:14:25 schrieb Oz Linden (Scott Lawrence):
>> On 2010-11-05 16:50, Henri Beauchamp wrote:
>> > To do this however, we'd need to know what is the license status of the
>> > UI sounds: does LL allow TPV developpers to distribute them (under the
>> > Artistic License, for example, like for the UI artwork), and if yes
>> > under which License ?
>>
>> At present, any sounds or other elements fetched by the viewer from the
>> asset server are for licensing purposes just assets.  As such, they are
>> subject to the rules on whether or not assets can be copied out to
>> external storage - that is, only if the user executing the copy is the
>> Creator of the asset.
>
> I do believe that clashes with the general idea of caching anything at all...
>
>
>
> bye,
> 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

Re: [opensource-dev] STORM-151 : KDU v6.4.1 upgrade update

[Marc Adored]

I can confirm that it loads textures quite a bit faster then previous
versions also. My system is Ubuntu 64bit and I noticed a pretty good
increase in texture load speed. TP'd to a few different places and
same result.

On Tue, Nov 23, 2010 at 12:11 AM, Trilo Byte  wrote:
> Installation went without a hitch, and wow, the performance improvement for
> texture loading is noticeable!  Just logging in at my studio (high altitude
> private space) texture loading was near instantaneous.  I then teleported to
> a few different locations at ground level, ranging from low density (fewer
> prims, judicious use of textures and sculpts) to high density (lots of
> prims, excessive use of sculpties and high resolution textures) builds, the
> experience was overwhelmingly positive.
> Loading textures from inventory did not seem improved over previous versions
> (if anything it may have been slower).  I'm not sure if the KDU upgrade
> wouldn't affect that, something still needs to be tuned, or if the asset
> server was just misbehaving.
>
> Also worth noting that Name Tags work in your build, something that's been
> broken in the main snowstorm development snapshots since 215139.
> Overall though, great progress.  I look forward to this getting refined and
> brought in as soon as possible.
> Trilo
> On Nov 22, 2010, at 2:06 PM, Philippe (Merov) Bossut wrote:
>
> Hi,
>
> On Fri, Nov 19, 2010 at 3:27 AM, Trilo Byte  wrote:
>>
>> Broken here as well, Merov.  After downloading and installing the DMG file
>> and attempting to run the application, I immediately get an error that
>> reads:
>> Second Life Developer cannot be opened because of a problem.
>> Check with the developer to make sure Second Life Developer works with
>> this version of Mac OS X.  You may need to reinstall the application.  Be
>> sure to install any available updates for the application and Mac OS X.
>> (I'm running OS X 10.6.5 btw).
>> Trilo
>
> Thanks for the tests Trilo and Katherine. This was underlying some much
> deeper issue that was also common to Windows (Linux didn't build). I had to
> review some cmake hacks I did when producing the libs and building the
> viewer with it. I went through all of it several times and I have now builds
> for the 3 platforms available at:
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-features/rev/215247/index.html
>
> I did test on all platforms and was able to run the viewers though I'm not
> going to be foolish that time around and claim victory before I get some
> feedback from you guys telling me that it works pretty much everywhere :)
>
> Note if you test those builds that compression (i.e. upload of textures) is
> not yet implemented.
>
> I also added STORM-151 on the list of builds to test and I'll update the
> link regularly from now on:
> https://wiki.secondlife.com/wiki/Downloading_test_builds#Developer_Builds
>
> Cheers,
> - 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
>
___
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] STORM-151 : KDU v6.4.1 upgrade update

[Marc Adored]

Works for me :D Same result very speedy decoding imo! Ubuntu 64bit

On Wed, Nov 24, 2010 at 1:15 AM, Philippe (Merov) Bossut
 wrote:
> Hi,
>
> On Mon, Nov 22, 2010 at 10:03 PM, Philippe (Merov) Bossut
>  wrote:
>>
>> Zha, I noticed that myself when building locally. I've been scratching my
>> head most of the afternoon as to why windows seems to be dynamically linked
>> instead of statically linked. It's the same cmake for all platforms... Well,
>> I clearly did something wrong in that case. Working on it...
>
> I worked on that today and got it working locally on my Windows machine. The
> Team City build went through and it's there:
> http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/merov_viewer-development-features/rev/215468/index.html
>
> I couldn't test Windows or Linux but if someone could give those a spin,
> that'd be swell.
>
> Cheers,
> - 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