From vector at leafpile.com Mon Sep 1 00:04:45 2008 From: vector at leafpile.com (Vector Hastings) Date: Mon Sep 1 00:04:48 2008 Subject: FW: [sldev] Request for help with modifying client camera behavior Message-ID: I just realized my general thank you to everyone didn't post to the board. Thank you everyone for your help in coming up with ideas. Now if I could only figure out how to make a simple build compile :-( Vector -----Original Message----- From: Vector Hastings [mailto:vector@leafpile.com] Sent: Tuesday, August 26, 2008 5:54 PM To: Vector Hastings Subject: RE: [sldev] Request for help with modifying client camera behavior Addendum: we're a sub-indie level production, so we haven't too much capital, but we do need this camera, so we're ready to discuss paying. All the best, Vector Hastings. -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Vector Hastings Sent: Tuesday, August 26, 2008 4:13 PM To: sldev@lists.secondlife.com Subject: [sldev] Request for help with modifying client camera behavior Hello all, I'm new to this list, never learned C++, but was once a pretty competent programmer on the IBM midrange platform. Please forgive a long first posting, but I've been trying other avenues (as this will make clear) and find myself needing to escalate to client hacking. A full treatment of what I'm seeking involves a certain amount of detail, which now follows: I'm trying to launch an ambitious filmmaking project inside Second Life (machinima). One of the critical keys to getting a more cinematic look to machinima in Second Life is better camera control. The ultimate goal is an in-world camera that can follow a fully reproducible, smooth, and non-colliding path. There's been a lot of work on that already: the 3dNavigator flycam gives us beautiful smooth paths, non-colliding behavior, focal-length control, but there is zero reproducibility. There are a number of waypoint systems that use a vehicle to move the avatar around, allowing for a somewhat reproducible path, but at the cost of collisions which are unacceptable in interior spaces, and the effect is often choppy and fine control of camera angles is not achieved with current systems (even though I suspect that last item is theoretically possible). I've experimented with making a system of waypoints trying to use the llSetCameraParams option to move just the av's camera. I believe this is the best middle-ground approach, and will achieve a major step forward in machinima cameras, but... The inherent desire of the camera to return to the filming avatar's default camera position means my filming results are so choppy that they're only useful for simulating an earthquake. :-\ I know that viewer code is in flux right now, so anything done now is at risk of having to be re-developed later. But I am also on deadlines, so I'm reaching out for guidance in how to do this. Ending up with an older client is workable for me. Hopefully the feature could be ultimately re-engineered for the more stable 1.21. (I'm also happy to use an RC 1.21 viewer, if it becomes usable on the main grid in the next two to three weeks. I was a long-time user of the last two RC candidates, doing a lot of our pre-production filming with them.) What I think I need is a hack of the client to solve the problem with my rig, and there's probably multiple approaches: 1. Create a debug setting that tells the camera to apply its native, manual-mode Cam Transition time and Cam Smoothing to changes in scripted camera location. This sounds relatively simple, since the initial entry and exit into scripted camera control obeys those parameters, but the movement from one location to another does not, which implies to me that the camera routines know whether they are under scripted control or not and have been set to behave in this instantaneous relocation mode when switching from one camera position and/or focus to the next. 2. Create a debug setting that turns off av camera target drift altogether. There are lag parameters in llSetCameraParams, but they only seem to be effective when position_locked = FALSE -- those lag parameters would give excellent speed control in the camera -- but right now, position_locked = FALSE means the camera pulls toward the owning avatar like it's attached with a giant rubber band, and the effect is a seesawing nightmare. 3. Create a flycam recorder. This might be a very general and powerful solution, but authoring a camera path with it would probably be unwieldy. One would want the ability to store a camera path log file to disk in a human readable format so that it could be tweaked into shape. That tweaking could perhaps be done with some sort of statistical analysis program, but I think it would take one dramatically outside the world of SL to do it. 4. Create a waypoint recorder in the client, that simply lets you hit a button to add a camera position/angle to the list of spots to hit, then reposition, add another point. It would be nice to have a speed control, and vital to be able to save it, and helpful to be able to edit it. This is the basics of the scripted waypoint systems in-world, including the one I'm working on. I downloaded the code last night, and went to the library to check out "teach yourself c++" today. Somebody have mercy on me, please! While I will initially use the camera system I develop on my project, as soon as we begin releasing episodes, I will also release the camera as a way of building good-will and buzz in the project. If you want to see a little about the project I'm cooking, you can visit www.vectorpicturestudios.com. All the best to you all, Vector Hastings _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From jpirkola at gmail.com Mon Sep 1 07:29:49 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Mon Sep 1 07:29:52 2008 Subject: [sldev] meet realXtend at LA VW Expo In-Reply-To: <9291786d0809010725r47328e47vd337f90112efd94e@mail.gmail.com> References: <9291786d0809010725r47328e47vd337f90112efd94e@mail.gmail.com> Message-ID: <9291786d0809010729p54f5ee21wdaee9ab266f1056b@mail.gmail.com> Dear all, f you wish to meet realXtend representatives at the Virtual Worlds 08 Expo in Los Angeles, you can meet us at the OpenSim booth if you're lucky and happen to be there at the right time and if you're not feeling lucky, you may email us and we'll try to setup a meeting. Contact us at hannu.hollstrom@adminotech.com tomi.kujanpaa@ludocraft.com antti.ilomaki@adminotech.com Thanks! Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080901/44c19ba8/attachment.htm From secondloop at gmail.com Mon Sep 1 15:37:17 2008 From: secondloop at gmail.com (azdel slade) Date: Mon Sep 1 15:37:19 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture Message-ID: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> hi, i'm trying to run maint-render-10 after a successful compile and build, but it fails with an error. running the downloaded client 1.20.15 works fine. but i have a new EVGA nvidia 9500 gt and it gives me an error that the card is unrecognized. looking at the error log, i thought it might help if i added the regex for my card to the gpu table, but it didn't. so attached is the proper regex for this card. is there a jira report where i should add this patch? or should i make one? here's the relevant part of the log. i tried setting my card's class to 0, 1, and 2, but it still has the same error every time. the card has 512mb of memory, but the log always says its setting max memory to 128mb and texture memory to 96mb and then it crashes. any idea how to fix this? The error message says "creategl texture failed to make texture" and then it exits. 2008-09-01T06:45:27Z WARNING: LLFeatureList::addFeature: LLFeatureList::Attempting to add preexisting feature Disregard128DefaultDrawDistance 2008-09-01T06:45:27Z INFO: LLFeatureManager::loadGPUClass: GPU is NVIDIA GeForce 9500GT 2008-09-01T06:45:27Z INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class0 2008-09-01T06:45:27Z INFO: LLFeatureManager::applyRecommendedSettings: Applying Recommended Features 2008-09-01T06:45:27Z INFO: LLFeatureManager::applyBaseMasks: Setting GPU Class to Class0 2008-09-01T06:45:27Z WARNING: LLFeatureManager::applyFeatures: AHHH! Control setting RenderNightBrightness does not exist! 2008-09-01T06:45:27Z INFO: LLViewerImageList::updateMaxResidentTexMem: Total Video Memory set to: 128 MB 2008-09-01T06:45:27Z INFO: LLViewerImageList::updateMaxResidentTexMem: Available Texture Memory set to: 96 MB 2008-09-01T06:45:27Z INFO: viewer_windows_exception_handler: Entering Windows Exception Handler... 2008-09-01T06:45:27Z INFO: LLAppViewer::handleViewerCrash: Handle viewer crash entry. 2008-09-01T06:45:27Z INFO: LLAppViewer::handleViewerCrash: Creating crash marker file C:\Documents and Settings\Administrator\Application Data\SecondLife\logs\SecondLife.error_marker the entire log is attached as well. i added in the ui elements for stereoscopic mode. i don't think this caused the crash. but i am trying to run it on a different machine from the one it was compiled on, because parallels mac doesn't support SL anymore and that's where i'm compiling. i'm still trying to update the patch from umich for stereo to apply to a recent maint-render build. any help would be awesome. thanks, azdel -------------- next part -------------- A non-text attachment was scrubbed... Name: gpu_table.txt.9500gt.patch Type: application/octet-stream Size: 540 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080901/23827189/gpu_table.txt.9500gt.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: SecondLife.log Type: application/octet-stream Size: 10031 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080901/23827189/SecondLife.obj From robin.cornelius at gmail.com Mon Sep 1 23:44:15 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 1 23:44:20 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture In-Reply-To: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> References: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> Message-ID: <48BCE0BF.80306@gmail.com> azdel slade wrote: > hi, > > i'm trying to run maint-render-10 after a successful compile and > build, but it fails with an error. running the downloaded client > 1.20.15 works fine. but i have a new EVGA nvidia 9500 gt and it gives > me an error that the card is unrecognized. You can add new cards to the gpu_table.txt if its not already listed but this could also be the symptom of not having the data files available. > The error message says "creategl texture failed to make texture" and > then it exits. > 2008-09-01T06:45:27Z WARNING: LLFeatureManager::applyFeatures: AHHH! > Control setting RenderNightBrightness does not exist! ^^^^^ is important to. to me it looks like your artwork is not the correct version and/or the .xml files with various viewer data are incorrect (some are contained within the artwork bundle). Ensure the artwork you are using matches the version in doc/asset_urls.txt. What build environment is this Visual Studio/Linux etc? Ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080902/a3b43e61/signature.pgp From vector at leafpile.com Tue Sep 2 12:06:26 2008 From: vector at leafpile.com (Vector Hastings) Date: Tue Sep 2 12:06:26 2008 Subject: [sldev] Any chance on a develop.py script that will set up a MSVS2005 Express environment? Message-ID: I tried to go through the C-Make build instructions. I couldn't get very far because I only have the MSVS 2005 Express version. When running the develop.py script, it checks the registry for the standard installs, but doesn't have a way to build for express. Has anyone created this, or know what to do to modify the script. Thanks for any help. Vector From robin.cornelius at gmail.com Tue Sep 2 12:10:33 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Sep 2 12:10:39 2008 Subject: [sldev] Any chance on a develop.py script that will set up a MSVS2005 Express environment? In-Reply-To: References: Message-ID: <48BD8FA9.2030201@gmail.com> Vector Hastings wrote: > I tried to go through the C-Make build instructions. > > I couldn't get very far because I only have the MSVS 2005 Express version. > When running the develop.py script, it checks the registry for the standard > installs, but doesn't have a way to build for express. > > Has anyone created this, or know what to do to modify the script. I assume this is the VSTool.exe? All that is doing is selecting secondlife-bin as the startup project and selecting RelWithDbgInfo as the build target. If you ignore the error it throws and set those yourself in VS2005 then that should work Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080902/d0bbafea/signature.pgp From soft at lindenlab.com Tue Sep 2 12:15:02 2008 From: soft at lindenlab.com (Soft) Date: Tue Sep 2 12:15:05 2008 Subject: [sldev] Any chance on a develop.py script that will set up aMSVS2005 Express environment? In-Reply-To: References: Message-ID: On Tue, Sep 2, 2008 at 2:06 PM, Vector Hastings wrote: > I tried to go through the C-Make build instructions. > > I couldn't get very far because I only have the MSVS 2005 Express version. > When running the develop.py script, it checks the registry for the standard > installs, but doesn't have a way to build for express. > > Has anyone created this, or know what to do to modify the script. > > Thanks for any help. Could you look for an equivalent registry key for the Express install location(s)? The build scripts could be updated to search for Express if the full product isn't present. From vector at leafpile.com Tue Sep 2 13:27:40 2008 From: vector at leafpile.com (Vector Hastings) Date: Tue Sep 2 13:27:41 2008 Subject: [sldev] Any chance on a develop.py script that will set up aMSVS2005 Express environment? In-Reply-To: Message-ID: I believe its: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress\8.0\Setup\VS Value name: ProductDir Type: REG_SZ Thank you! Vector -----Original Message----- From: brian@brianm.org [mailto:brian@brianm.org]On Behalf Of Soft Sent: Tuesday, September 02, 2008 12:15 PM To: Vector Hastings Cc: Second Life Developer Mailing List Subject: Re: [sldev] Any chance on a develop.py script that will set up aMSVS2005 Express environment? On Tue, Sep 2, 2008 at 2:06 PM, Vector Hastings wrote: > I tried to go through the C-Make build instructions. > > I couldn't get very far because I only have the MSVS 2005 Express version. > When running the develop.py script, it checks the registry for the standard > installs, but doesn't have a way to build for express. > > Has anyone created this, or know what to do to modify the script. > > Thanks for any help. Could you look for an equivalent registry key for the Express install location(s)? The build scripts could be updated to search for Express if the full product isn't present. From chess at us.ibm.com Tue Sep 2 13:45:40 2008 From: chess at us.ibm.com (David M Chess) Date: Tue Sep 2 13:45:44 2008 Subject: [sldev] New page in Wiki for gathering thoughts about IM interop Message-ID: In the last couple of Zero office hours / AWG meetings people've started to bring up ideas about how group IM can best work scalably in OGP. If we do a good enough job here, it might even help LL fix group chat in SL. :) I've put up a Wiki page to gather thoughts here: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP and I've filled in a very skeletal structure of the thoughts that I retained from the last couple of discussions. Everyone is urged to read and contribute, as always... Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080902/4cad6801/attachment.htm From chess at us.ibm.com Tue Sep 2 13:57:59 2008 From: chess at us.ibm.com (David M Chess) Date: Tue Sep 2 13:58:03 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080806190044.302881139C9@stupor.lindenlab.com> Message-ID: Ha, that's what I get for posting before reading. As I said in a brand-new thread recently rather than sensibly posting to this one (because I haven't seen it yet), this "what shall we use for group IM in OGP?" discussion (which is closely related to a "how can SL group IM be fixed?" discussion) has gotten serious enough lately that I've started a Wiki page about it: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP Comments and contributions are very extremely welcome. IMHO "just hook it up to IRC" is overlooking some important details, like exactly how do my credentials flow from the Agent Domain or SL or whatever to the IRC server, so we don't lose our current reasonably strong confidence that the names we're seeing in the IM window are actually the SL names of the ppl who said the things, and that no one not in the group is listening. It's possible that those details are easy to work out, and that'd be great, but I'll believe it when I see it written down. :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080902/451c6a9a/attachment.htm From intertricity at gmail.com Tue Sep 2 14:14:12 2008 From: intertricity at gmail.com (Judd Jackson) Date: Tue Sep 2 14:14:15 2008 Subject: [sldev] Avatar eye bone rotation constraints Message-ID: Hey, in relation to Domino's avatar work ( http://dominodesigns.info/ ) I was wondering if anybody knew the rotation constraints for the avatar eyeballs- it would really be helpful to know the extreme boundaries of where the eyes can look. Any information would be helpful, thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080902/de2a66be/attachment.htm From monkowsk at watson.ibm.com Tue Sep 2 15:05:45 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Sep 2 15:07:15 2008 Subject: [sldev] Avatar eye bone rotation constraints In-Reply-To: References: Message-ID: <48BDB8B9.2080603@watson.ibm.com> in indra/llcharacter/llheadrotmotion.cpp const F32 EYE_ROT_LIMIT_ANGLE = F_PI_BY_TWO * 0.3f; //max angle in radians for eye rotation Judd Jackson wrote: > Hey, in relation to Domino's avatar work ( http://dominodesigns.info/ ) > I was wondering if anybody knew the rotation constraints for the avatar > eyeballs- it would really be helpful to know the extreme boundaries of > where the eyes can look. Any information would be helpful, thanks! From secondloop at gmail.com Tue Sep 2 16:07:21 2008 From: secondloop at gmail.com (azdel slade) Date: Tue Sep 2 16:07:23 2008 Subject: [sldev] maint-render-10 crashes at launch, can't create texture In-Reply-To: <48BCE0BF.80306@gmail.com> References: <1e0ce1090809011537t452ed8e7n230d8cba4b8b2728@mail.gmail.com> <48BCE0BF.80306@gmail.com> Message-ID: <1e0ce1090809021607o7ea523f4gd6d077b97e63b883@mail.gmail.com> It's msvs 2005 pro. I'll check the asset urls tonight, but i'm sure that's where i got the assets from. excelt for llkdu.dll, which i dl'ed from the latest src download because it wasn't included. On Mon, Sep 1, 2008 at 11:44 PM, Robin Cornelius wrote: > azdel slade wrote: >> hi, >> >> i'm trying to run maint-render-10 after a successful compile and >> build, but it fails with an error. running the downloaded client >> 1.20.15 works fine. but i have a new EVGA nvidia 9500 gt and it gives >> me an error that the card is unrecognized. > > You can add new cards to the gpu_table.txt if its not already listed but > this could also be the symptom of not having the data files available. > >> The error message says "creategl texture failed to make texture" and >> then it exits. > >> 2008-09-01T06:45:27Z WARNING: LLFeatureManager::applyFeatures: AHHH! >> Control setting RenderNightBrightness does not exist! > > ^^^^^ is important to. to me it looks like your artwork is not the > correct version and/or the .xml files with various viewer data are > incorrect (some are contained within the artwork bundle). > > Ensure the artwork you are using matches the version in doc/asset_urls.txt. > > What build environment is this Visual Studio/Linux etc? > > Ac > > > From mark at identityserver.net Wed Sep 3 04:31:55 2008 From: mark at identityserver.net (Domino Marama) Date: Wed Sep 3 04:32:06 2008 Subject: [sldev] Avatar eye bone rotation constraints In-Reply-To: References: Message-ID: <1220441515.6630.15.camel@domino-laptop> On Tue, 2008-09-02 at 17:14 -0400, Judd Jackson wrote: > Hey, in relation to Domino's avatar work > ( http://dominodesigns.info/ ) I was wondering if anybody knew the > rotation constraints for the avatar eyeballs- it would really be > helpful to know the extreme boundaries of where the eyes can look. Any > information would be helpful, thanks! Don't trust my skeleton too much yet. It is going to change. On the first attempt it seemed sensible to use bones to represent the joints, now I think I should have used empties and used constraints to attach the mesh deformation bones to them. It'll simplify things when I get to importing and exporting bvh files as they are essentially an empty based driver system. Have Fun! Domino From grant at lindenlab.com Wed Sep 3 10:28:49 2008 From: grant at lindenlab.com (Grant Linden) Date: Wed Sep 3 10:28:52 2008 Subject: [sldev] RX Office hours - Erica Linden will host a brainstorming session on new resident starting locations Message-ID: <907af5560809031028u3a69939dqecb0e999078dcf6b@mail.gmail.com> Erica Linden will host a brainstorming session on new resident starting locations - what would your dream "Orientation Island" look like? Focusing on new residents of all stripes. Thursday August 4th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080903/ac932e5e/attachment.htm From bos at lindenlab.com Wed Sep 3 11:26:40 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Sep 3 11:26:42 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: <48B952E0.2030804@gmail.com> References: <48B952E0.2030804@gmail.com> Message-ID: Hi, Robin - Thanks for bringing these up. > 1) The Viewer source is HARD depending on the artwork. > http://jira.secondlife.com/browse/VWR-8885 I've assigned this to myself, and will fix it tomorrow. > 2) glh/glh_linear.h > > This has again moved and is now included with the downloaded libs at the > start of the cmake process. This is not helpful when building > standalone. The header is not included anywhere else and does not appear > to be used by any other packages i can find within debain for example so > i really think this should included with the viewer source not appended > as a lib. Fair enough. Can you file a VWR against this, please? > > 3) Ability to rename binary > > The binary is hard coded to secondlife-bin this could do with being > override able from the build options, due to the old trademark issues. > No problem. Again, filing a bug will help to have this not fall through the cracks. > 4) Install > > The only way i can see to achieve this is to patch the build system as > cmake will not respect the CMAKE_INSTALL_PREFIX if the locations are an > absolute path. > This is something you'll want to bring up with the CMake developers, since I know nothing about their install process. If there are any changes needed on our side, please file a bug with a patch and I'll incorporate it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080903/e4281ed7/attachment.htm From bill.hoffman at kitware.com Wed Sep 3 11:56:37 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Sep 3 11:56:52 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: References: <48B952E0.2030804@gmail.com> Message-ID: <48BEDDE5.1030902@kitware.com> Bryan O'Sullivan wrote: > > > 4) Install > > The only way i can see to achieve this is to patch the build system as > cmake will not respect the CMAKE_INSTALL_PREFIX if the locations are an > absolute path. > If you use absolute paths, then you should use DESTDIR. make DESTDIR=/my/special/path -Bill From bill.hoffman at kitware.com Wed Sep 3 12:13:06 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Sep 3 12:13:21 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: <48BEDDE5.1030902@kitware.com> References: <48B952E0.2030804@gmail.com> <48BEDDE5.1030902@kitware.com> Message-ID: <48BEE1C2.8060907@kitware.com> Bill Hoffman wrote: > Bryan O'Sullivan wrote: > >> >> >> 4) Install >> >> The only way i can see to achieve this is to patch the build >> system as >> cmake will not respect the CMAKE_INSTALL_PREFIX if the locations >> are an >> absolute path. >> > If you use absolute paths, then you should use DESTDIR. > > make DESTDIR=/my/special/path > > -Bill > That is: make DESTDIR=/my/special/path install -Bill From vector at leafpile.com Wed Sep 3 14:38:55 2008 From: vector at leafpile.com (Vector Hastings) Date: Wed Sep 3 14:38:56 2008 Subject: [sldev] Getting CMake error: Failed to download or unpack prebuilt 'ogg-vorbis' Message-ID: I'm following the http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake instructions, and I'm stuck here where Ricky was last month. CMake is registering the build engine, but sends me this message: Failed to download or unpack prebuilt 'ogg-vorbis' I get this message whether I use the python script from the command line, or go into the CMake program and hand-select: source library = C:\sl_cmake_1_20_15\trunk\indra build library = C:\sl_cmake_1_20_15\linden\indra\build I re-downloaded the trunk files via svn today. Help! Vector From bos at lindenlab.com Wed Sep 3 15:56:49 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Sep 3 15:56:51 2008 Subject: [sldev] XML files in artwork (Cmake standalone build issues) In-Reply-To: <48B9A443.8090000@lindenlab.com> References: <48B952E0.2030804@gmail.com> <48B9A443.8090000@lindenlab.com> Message-ID: On Sat, Aug 30, 2008 at 12:49 PM, Rob Lanphier wrote: > > I'm going to guess that this should actually be moved to the source > bundle rather than remain in the artwork bundle, but I need to ask > around about this, and perhaps do a little poking around myself. It should just be optional. We haven't required artwork to be present to build the standalone GPL viewer in the past, and the current situation is an accident. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080903/85b958e3/attachment.htm From q at lindenlab.com Wed Sep 3 16:06:13 2008 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Wed Sep 3 16:06:17 2008 Subject: [sldev] Linden's new Sustaining Engineering group Message-ID: <469A0D35-E3CF-41DA-B85F-9DB1767599E7@lindenlab.com> Hi, everyone. This message is just a little announcement about a change we've made at Linden Lab recently (about a month ago now) -- we've created a group of people whose job is explicitly to focus on what's known as "Sustaining Engineering" for the viewer. Basically, that's doing the maintenance to keep the heat on and the roof from leaking. I'm the manager of the Sustaining Engineering group, and on the team are some people you've seen on this list -- Soft, Tofu, and Coco. In particular, our charter is: * Handling viewer bugs. This is defined partly by what it's not -- namely, it's not architecture, and it's not anything that requires significant refactoring or changes the user interface in significant ways. But it is annoyances and UI glitches as well as programming errors. * Handling "featurettes". These are the small features that make people's lives easier or fix UI inconsistencies. Recent examples included moving some menu items, enabling and disabling buttons at key times, and the feature that allows dropping inventory directly onto an IM window. * Handling open source patches. Yes! We now have people at LL whose job is, explicitly, importing patches and getting them into the release. We've been trying, in recent weeks, to be very responsive to patches submitted, and explicit about what we're doing with them. It doesn't mean we'll take every patch thrown at us, but I hope that when we don't take them, we'll be able to give better guidance as to why. What you should see from us in the next few weeks/months: * An increased attention to patch submissions in the PJIRA. We do a weekly internal triage of issues in PJIRA, and our priority is to first consider issues with patches, then new issues, and finally to revisit issues that have already been considered but need additional action or are getting old. As I said above, our goal is to respond to all patches rather than letting them languish, even if the response is "we can't take this". * Aggregation of PJIRA issues into related topics. You saw this earlier this week with Rob's post on patch bundling for Chat/IM messages, but we hope to do a lot more of that, and to enlist this community in tackling collections of related issues in a timely fashion. * An improvement with respect to reflecting accurate status in PJIRA. A common phrase in our triage now is "will you please update the PJIRA?" * A gradual improvement in patch throughput from submission through to release or at least visible builds. This is a general Linden Lab issue -- our release process is long right now -- but the Sustaining group can help by aggregating issues through release in a timely fashion. We can also try to publish branches as early as possible in our development process. I'm very excited about this new group. I will continue to show up at the weekly open source meetings, at my own office hour, and I will try to come to the public triage meetings when I can. I also read this list and from time to time log in on the #opensl IRC channel. In short, I'm pretty easy to find -- please come talk to me. Q From GordonWendt at gmail.com Wed Sep 3 19:42:56 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Sep 3 19:42:59 2008 Subject: [sldev] Linden's new Sustaining Engineering group In-Reply-To: <469A0D35-E3CF-41DA-B85F-9DB1767599E7@lindenlab.com> References: <469A0D35-E3CF-41DA-B85F-9DB1767599E7@lindenlab.com> Message-ID: <493033a70809031942t3437cfcaw8c52a8565f35874a@mail.gmail.com> That's great if you guys can actually come through and prove that your up to it hopefully if LL can show that this change of course is for real some of the really great opensource people, like Nicholaz Beresford, that have been scared away by LL's previous negligent attitude towards the patch submitters and open source coding community will come back. That's the hope at least. Q, with all due honesty if you can do it then great, fight the good fight and all the other cliches and prove that you can do it but you're going to face a wall of skepticism for awhile due to LL's former practices which pissed off and pushed away people who were actually eager to help you so good luck to you if you really can do it but don't expect the community to get their hopes up on this at least until you can show that your team can make results and are a true change of course. -G.W. From nolan-paul at btconnect.com Thu Sep 4 01:36:33 2008 From: nolan-paul at btconnect.com (Paul Nolan) Date: Thu Sep 4 01:36:38 2008 Subject: [sldev] Linden's new Sustaining Engineering group In-Reply-To: <469A0D35-E3CF-41DA-B85F-9DB1767599E7@lindenlab.com> References: <469A0D35-E3CF-41DA-B85F-9DB1767599E7@lindenlab.com> Message-ID: <54AFEF3E-D00A-4B1C-B6C2-91DC1C7E0C51@btconnect.com> Hi, I'm really interested in this change; and wnat to be a part of it. with that aim in mind, I have a suggestion I hope you'll entertain. I assume you are going to be deciding which viewer-bugs- and-'featurettes' fail within the domain of this group. If so, would you mark Jira entries in such a way that they become searchable (keyword, category, etc - whatever will be easiest). The sort of annotation that would allow a Jira Subscription email filter that listed the 'Sustaining Engineering issues : unresolved and available for opensl developers to work on' Personally, this is the sort of contribution I prefer to make; small and discrete changes I can work on and deliver in my spare time. This is the type of patch I've submitted in the past (yes, I know it's been a while - working for a living, family, old house in need of 'sustaining engineering' 8-) etc ) and is the type of work I'd like to do more of. Cheers Paul --- RL: Paul Nolan SL : Paul Churchill On 4 Sep 2008, at 00:06, Kent Quirk (Q Linden) wrote: > Hi, everyone. > > This message is just a little announcement about a change we've made > at Linden Lab recently (about a month ago now) -- we've created a > group of people whose job is explicitly to focus on what's known as > "Sustaining Engineering" for the viewer. Basically, that's doing the > maintenance to keep the heat on and the roof from leaking. > > I'm the manager of the Sustaining Engineering group, and on the team > are some people you've seen on this list -- Soft, Tofu, and Coco. > > In particular, our charter is: > > * Handling viewer bugs. This is defined partly by what it's not -- > namely, it's not architecture, and it's not anything that requires > significant refactoring or changes the user interface in significant > ways. But it is annoyances and UI glitches as well as programming > errors. > > * Handling "featurettes". These are the small features that make > people's lives easier or fix UI inconsistencies. Recent examples > included moving some menu items, enabling and disabling buttons at > key times, and the feature that allows dropping inventory directly > onto an IM window. > > * Handling open source patches. Yes! We now have people at LL whose > job is, explicitly, importing patches and getting them into the > release. We've been trying, in recent weeks, to be very responsive > to patches submitted, and explicit about what we're doing with them. > It doesn't mean we'll take every patch thrown at us, but I hope that > when we don't take them, we'll be able to give better guidance as to > why. > > What you should see from us in the next few weeks/months: > > * An increased attention to patch submissions in the PJIRA. We do a > weekly internal triage of issues in PJIRA, and our priority is to > first consider issues with patches, then new issues, and finally to > revisit issues that have already been considered but need additional > action or are getting old. As I said above, our goal is to respond > to all patches rather than letting them languish, even if the > response is "we can't take this". > > * Aggregation of PJIRA issues into related topics. You saw this > earlier this week with Rob's post on patch bundling for Chat/IM > messages, but we hope to do a lot more of that, and to enlist this > community in tackling collections of related issues in a timely > fashion. > > * An improvement with respect to reflecting accurate status in > PJIRA. A common phrase in our triage now is "will you please update > the PJIRA?" > > * A gradual improvement in patch throughput from submission through > to release or at least visible builds. This is a general Linden Lab > issue -- our release process is long right now -- but the Sustaining > group can help by aggregating issues through release in a timely > fashion. We can also try to publish branches as early as possible in > our development process. > > > I'm very excited about this new group. I will continue to show up at > the weekly open source meetings, at my own office hour, and I will > try to come to the public triage meetings when I can. I also read > this list and from time to time log in on the #opensl IRC channel. > In short, I'm pretty easy to find -- please come talk to me. > > Q > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From robin.cornelius at gmail.com Thu Sep 4 02:04:21 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Sep 4 02:04:25 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: References: <48B952E0.2030804@gmail.com> Message-ID: Thanks Bryan, jira's and info inline below:- On Wed, Sep 3, 2008 at 7:26 PM, Bryan O'Sullivan wrote: >> 2) glh/glh_linear.h >> >> This has again moved and is now included with the downloaded libs at the >> start of the cmake process. This is not helpful when building >> standalone. The header is not included anywhere else and does not appear >> to be used by any other packages i can find within debain for example so >> i really think this should included with the viewer source not appended >> as a lib. > > Fair enough. Can you file a VWR against this, please? http://jira.secondlife.com/browse/VWR-9005 >> >> 3) Ability to rename binary >> >> The binary is hard coded to secondlife-bin this could do with being >> override able from the build options, due to the old trademark issues. > > No problem. Again, filing a bug will help to have this not fall through the > cracks. http://jira.secondlife.com/browse/VWR-8889 Patch attached to that one that I am currently using in my packaging. Thanks Robin From robin.cornelius at gmail.com Thu Sep 4 02:06:25 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Sep 4 02:06:28 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: <48BEE1C2.8060907@kitware.com> References: <48B952E0.2030804@gmail.com> <48BEDDE5.1030902@kitware.com> <48BEE1C2.8060907@kitware.com> Message-ID: On Wed, Sep 3, 2008 at 8:13 PM, Bill Hoffman wrote: > Bill Hoffman wrote: >> >> Bryan O'Sullivan wrote: >> >>> >>> 4) Install >>> >>> The only way i can see to achieve this is to patch the build system as >>> cmake will not respect the CMAKE_INSTALL_PREFIX if the locations are >>> an >>> absolute path. > That is: > > make DESTDIR=/my/special/path install > Ah cool, sounds good. Did not spot this on the cmake instructions. With any luck this will now allow me to use cmakes install target to install the files to the packaging staging area Many thanks Robin From robin.cornelius at gmail.com Thu Sep 4 02:10:04 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Sep 4 02:10:09 2008 Subject: [sldev] Rob's hours tonight Message-ID: Is Rob's hour tonight still happening, though i would check, with SLCC this weekend, not sure if Rob was going to be on his way to/already there/preparing etc? Robin From edward.artaud at gmail.com Thu Sep 4 08:30:40 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Thu Sep 4 08:30:44 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080806190044.302881139C9@stupor.lindenlab.com> Message-ID: One question I'd ask is does the announcement of SLim and it's mechanism for integration mean that it's not necessary for chat in the future to use OGP? My understanding is that the SLim integration is connecting you to a separate IM network (the Vivox one) in parallel to your connection to the grid. It should be fairly simple to use this same approach to connect to other IM networks such as Jabber/GTalk if LL is now officially using this approach to open up IM. The only challenge would be that some sort of central SL name to (for example) GTalk name database would need to be maintained. If chat integration can occur purely at the viewer level without all the attendent headaches of going though the grid, then it would seem such work could happen fairly quickly, which is undoubtedly why LL is now using this approach with it's newly announced features. On Tue, Sep 2, 2008 at 1:57 PM, David M Chess wrote: > > Ha, that's what I get for posting before reading. As I said in a brand-new > thread recently rather than sensibly posting to this one (because I haven't > seen it yet), this "what shall we use for group IM in OGP?" discussion > (which is closely related to a "how can SL group IM be fixed?" discussion) > has gotten serious enough lately that I've started a Wiki page about it: > > https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/f2af81ca/attachment.htm From liana at lindenlab.com Thu Sep 4 08:51:31 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Thu Sep 4 08:51:02 2008 Subject: [sldev] RSVP: Hippo Award Winners Announcement Message-ID: <48C00403.1000603@lindenlab.com> Dear SLdev-ers: This Saturday, September 6th, Rob Linden will announce the winners of the 2008 Hippo Awards for open source community work at the Second Life Community Convention. If you are attending SLCC, do introduce yourself to Rob. Concurrently, I will be hosting a small gathering of Hippo nominees and Linden judges in Second Life where we plan to tune-in to Rob's announcement and celebrate this year's winners and all that the community has accomplished. If you'd like to attend the in-world gathering, please RSVP to me as soon as possible. Seating is limited. This will be a voice-enabled event. What: In-world Hippo Awards gathering When: Saturday, Sept. 6th, 3pm EDT/noon PDT Where: Hippotropolis Theater Best, Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/0c4a2ac4/attachment.htm From gbrandon at gmail.com Thu Sep 4 09:14:48 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Thu Sep 4 09:14:51 2008 Subject: [sldev] New slvoice functionality? Message-ID: Hi! I am the creator of VoiceBox, the app that allows residents to make and receive voice calls without logging their avatar in to Second Life. While working with slvoice, I noticed the EnableBuddiesAndPresence and the JoinText stuff and how they didn't work at the time. However, following the announcement of SLim, I decided to try again, and noticed that those features seem to be enabled now! Unfortunately it seems (correct me if I'm wrong) that the currently available slvoice.exe doesn't have the functionality for sending and receiving text chat, or using a buddies system. I don't know what to try and am stumped :) Is there a more current version of the documentation or anything at all that will point me in the right direction? Or am I breaking a law or something? Thanks and best wishes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/0bef20c2/attachment.htm From phoenix at secondlife.com Thu Sep 4 09:41:51 2008 From: phoenix at secondlife.com (Phoenix) Date: Thu Sep 4 09:42:44 2008 Subject: [sldev] Attending SLCC Message-ID: <494891A1-91D1-4A8E-90F8-A9034C8BF65E@secondlife.com> Howdy folks. If anyone from sldev will be in Tampa for SLCC, I plan to be there from Friday night to Sunday morning. I would love to meet any of the new or old residents that are working on the code to help explain some of the oddities you've encountered, help sketch preliminary designs and potential coding directions for new things you are working on, and give a glimpse into how we plan to roll forward with open source code integration and coming viewer code and projects. So really bring your questions, compliments, or complaints, and let's talk. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080904/5a913a6f/PGP.pgp From phoenix at secondlife.com Thu Sep 4 10:50:47 2008 From: phoenix at secondlife.com (Phoenix) Date: Thu Sep 4 10:51:39 2008 Subject: [sldev] Getting CMake error: Failed to download or unpack prebuilt 'ogg-vorbis' In-Reply-To: References: Message-ID: <19C67DDF-C512-49DD-8F7E-D078F7B0B584@secondlife.com> Hi there Vector. The error message you're seeing is from the Prebuilt.cmake script which is our cmake interface into install.py which is responsible for plucking the prebuilt binaries off of a web server and installing into your tree. This is driven by reading the install.xml and installed.xml files and deciding what to fetch based on platform. If you have cygwin, you should be able to run the commands: $ cd scripts; ./install.py ogg-vorbis and see if that does the right thing. If that does not work, can you open up install.xml and find the ogg-vobis section, and then locate the windows subsection which will have an url along the lines of: http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/ogg- vorbis-1.03-1.1.2-windows-20080613.tar.bz2 Can you find the url you have and reply with it? Next, in installed.xml, can you find the ogg-vorbis section and copy the files section in your reply? On 2008-09-03, at 14:38, Vector Hastings wrote: > I'm following the > http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake > instructions, > > and I'm stuck here where Ricky was last month. > > CMake is registering the build engine, but sends me this message: > > Failed to download or unpack prebuilt 'ogg-vorbis' > > I get this message whether I use the python script from the command > line, or > go into the CMake program and hand-select: > source library = C:\sl_cmake_1_20_15\trunk\indra > build library = C:\sl_cmake_1_20_15\linden\indra\build > > I re-downloaded the trunk files via svn today. > > Help! > > Vector > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080904/431f3b3b/PGP.pgp From gigstaggart at gmail.com Thu Sep 4 11:28:48 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Sep 4 11:28:59 2008 Subject: [sldev] RSVP: Hippo Award Winners Announcement In-Reply-To: <48C00403.1000603@lindenlab.com> References: <48C00403.1000603@lindenlab.com> Message-ID: <48C028E0.7010905@gmail.com> I might as well take this opportunity to mention the open source track at SLCC. It will be Saturday the 6th in the afternoon and will include the Hippo Award presentation. The slconvention.org site is down, but I've been told by the main organizers that you will be able to register and pay at the door in cash. From labrat.hb at gmail.com Thu Sep 4 12:26:27 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Sep 4 12:26:34 2008 Subject: [sldev] Vivox Opening the source to SLVoice Message-ID: Seems in all the talk about SLim and such, this little tidbit of information was overlooked. Vivox Inc., the market leader in voice services for developers of online > games and virtual worlds, today announced the availability of the Vivox Open > Initiative. By opening its code and network, the Vivox Open Initiative will > expand the reach of communications in and out of online games and virtual > worlds while accelerating the development of new and innovative features. > > The Vivox Open Initiative will be rolled out in phases. In the first phase, > launching today, Vivox will provide the object code for SL Voice, the Second > Life voice chat client. By the end of the year, Vivox will open APIs to > third party technology providers. Soon thereafter, Vivox will open up source > code to the client side SDK. > http://www.vivox.com/pressreleases_detail.php?id=37 http://www.vivox.com/open/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/307c025a/attachment.htm From vector at leafpile.com Thu Sep 4 12:28:16 2008 From: vector at leafpile.com (Vector Hastings) Date: Thu Sep 4 12:28:14 2008 Subject: [sldev] Newbie questions about a binary Message-ID: I've just succeeded in getting a binary out of the old windows path, using MSVS 2005 Express. I performed all the steps in http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 including the optional removals at the end. I have two questions right off (and they may be related). 1. My new program runs an external console window. I think this is the one turned off with Advanced>Console Window. But even though I turn it off and restart the program, it starts back up with it showing. 2. My new binary is 30% larger than the distributed one. 20,352 KB vs. 15,700 KB. It's compiled from the linden\indra\intra_complete\indra_complete.sln solution, using the Release configuration. (ReleaseNoOpt is the only other configuration that compiles for me, and it's even larger.) Neither by itself is a terrible problem, but they may bespeak things which are problems (particularly performance, since the binary is larger. Any insight? I'm very newb to this environment, so anything is helpful. Thanks to all. Vector From gigstaggart at gmail.com Thu Sep 4 12:44:54 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Sep 4 12:45:10 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: References: Message-ID: <48C03AB6.3090907@gmail.com> Harold Brown wrote: > Seems in all the talk about SLim and such, this little tidbit of > information was overlooked. > > Vivox Inc., the market leader in voice services for developers of > online games and virtual worlds, today announced the availability > of the Vivox Open Initiative. By opening its code and network, the > Vivox Open Initiative will expand the reach of communications in > and out of online games and virtual worlds while accelerating the > development of new and innovative features. > > The Vivox Open Initiative will be rolled out in phases. In the > first phase, launching today, Vivox will provide the object code > for SL Voice, the Second Life voice chat client. By the end of the > year, Vivox will open APIs to third party technology providers. > Soon thereafter, Vivox will open up source code to the client side > SDK. > That's cool, but what is the point of the object files? The license that you have to agree to to get these object files is much much more restrictive than the license on the documentation we already had. Anyone that really wants to tinker with this stuff can't agree to a license that says they can't write anything "productive" or "reverse engineer" anything, especially if we are provided with binary objects, and no headers. I mean, it's a step in the right direction in theory, but I'm not sure what we are supposed to do with this. -Jason From danteferret at gmail.com Thu Sep 4 13:22:45 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Sep 4 13:22:48 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: <48C03AB6.3090907@gmail.com> References: <48C03AB6.3090907@gmail.com> Message-ID: <4d211a610809041322w7d00eb12p722e2aba28971a7a@mail.gmail.com> Really, you can't do anything with it. And they have made sure of that. The license is so strict you can barely even tell anyone that you have downloaded this stuff. Right now you can download it and view the files in windows explorer, or whatever file browser you use. *laughs* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/ef4c9913/attachment.htm From robla at lindenlab.com Thu Sep 4 13:29:39 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 4 13:29:44 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: References: Message-ID: <48C04533.4020200@lindenlab.com> Hi all, I'd like to point out that Vivox has also set up both a public mailing list and direct point of contact for private inquiries: Public mailing list: https://lists.vivox.com/mailman/listinfo/vivox-open Private email inquiries: open@vivox.com We're really happy that Vivox has made a public commitment to opening up the source code for the voice component of the Second Life viewer. I'm not in a great position to say more about this, but I'd encourage you to join their list and discuss. Rob On 9/4/08 12:26 PM, Harold Brown wrote: > Seems in all the talk about SLim and such, this little tidbit of > information was overlooked. > > Vivox Inc., the market leader in voice services for developers of > online games and virtual worlds, today announced the availability > of the Vivox Open Initiative. By opening its code and network, the > Vivox Open Initiative will expand the reach of communications in > and out of online games and virtual worlds while accelerating the > development of new and innovative features. > > The Vivox Open Initiative will be rolled out in phases. In the > first phase, launching today, Vivox will provide the object code > for SL Voice, the Second Life voice chat client. By the end of the > year, Vivox will open APIs to third party technology providers. > Soon thereafter, Vivox will open up source code to the client side > SDK. > > > > http://www.vivox.com/pressreleases_detail.php?id=37 > > http://www.vivox.com/open/ > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From ordinal.malaprop at fastmail.fm Thu Sep 4 13:38:00 2008 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Thu Sep 4 13:38:04 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: <48C04533.4020200@lindenlab.com> References: <48C04533.4020200@lindenlab.com> Message-ID: Well, I would certainly say that it was better than them _not_ having said anything. To be honest, though, a promise to release APIs by the end of the year (which means next year at the earliest) and source after that at some point (which means 2010) is not all that useful for developers working with the SL client, I would warrant. I am not a developer working with the SL client as yet but I would not advise anyone to hold their breath. Personally speaking I still hold out hope for an XMPP bridge though I believe that shows my age. On 4 Sep 2008, at 21:29, Rob Lanphier wrote: > Hi all, > > I'd like to point out that Vivox has also set up both a public mailing > list and direct point of contact for private inquiries: > > Public mailing list: > https://lists.vivox.com/mailman/listinfo/vivox-open > > Private email inquiries: open@vivox.com > > We're really happy that Vivox has made a public commitment to > opening up > the source code for the voice component of the Second Life viewer. > I'm > not in a great position to say more about this, but I'd encourage > you to > join their list and discuss. > > Rob > > On 9/4/08 12:26 PM, Harold Brown wrote: >> Seems in all the talk about SLim and such, this little tidbit of >> information was overlooked. >> >> Vivox Inc., the market leader in voice services for developers of >> online games and virtual worlds, today announced the availability >> of the Vivox Open Initiative. By opening its code and network, the >> Vivox Open Initiative will expand the reach of communications in >> and out of online games and virtual worlds while accelerating the >> development of new and innovative features. >> >> The Vivox Open Initiative will be rolled out in phases. In the >> first phase, launching today, Vivox will provide the object code >> for SL Voice, the Second Life voice chat client. By the end of the >> year, Vivox will open APIs to third party technology providers. >> Soon thereafter, Vivox will open up source code to the client side >> SDK. >> >> >> >> http://www.vivox.com/pressreleases_detail.php?id=37 >> >> http://www.vivox.com/open/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From edward.artaud at gmail.com Thu Sep 4 13:46:35 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Thu Sep 4 13:46:39 2008 Subject: [sldev] SLim (was Replacing current group chat with XMPP?) Message-ID: One question I'd ask is does the announcement of SLim and it's mechanism for integration mean that it's not necessary for chat in the future to use OGP? My understanding is that the SLim integration is connecting you to a separate IM network (the Vivox one) in parallel to your connection to the grid. It should be fairly simple to use this same approach to connect to other IM networks such as Jabber/GTalk if LL is now officially using this approach to open up IM. The only challenge would be that some sort of central SL name to (for example) GTalk name database would need to be maintained. If chat integration can occur purely at the viewer level without all the attendent headaches of going though the grid, then it would seem such work could happen fairly quickly, which is undoubtedly why LL is now using this approach with it's newly announced features. On Tue, Sep 2, 2008 at 1:57 PM, David M Chess wrote: > > Ha, that's what I get for posting before reading. As I said in a brand-new thread recently rather than sensibly posting to this one (because I haven't seen it yet), this "what shall we use for group IM in OGP?" discussion (which is closely related to a "how can SL group IM be fixed?" discussion) has gotten serious enough lately that I've started a Wiki page about it: > > https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP > > From soft at lindenlab.com Thu Sep 4 13:51:54 2008 From: soft at lindenlab.com (Soft) Date: Thu Sep 4 13:51:58 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: <48C04533.4020200@lindenlab.com> References: <48C04533.4020200@lindenlab.com> Message-ID: Keep in mind that the best thing you can do is to make a business case on their list, and to show where you're willing to work with them. Pointing out the kinds of bugs you've helped squash in SL or pointing to value added viewer projects you've worked on would convince them that there's a community ready to give a lot back if they give out their source. Talking about features you'd like to help add to an open source voice product would be productive as well. Please don't delve into demands and accusations - make a persuasive case that they're missing out if you'd like things to move faster or differently. There's not much else we can accomplish toward the end of opening their product on our own list, but best luck in helping the push! On Thu, Sep 4, 2008 at 3:29 PM, Rob Lanphier wrote: > Hi all, > > I'd like to point out that Vivox has also set up both a public mailing > list and direct point of contact for private inquiries: > > Public mailing list: > https://lists.vivox.com/mailman/listinfo/vivox-open > > Private email inquiries: open@vivox.com > > We're really happy that Vivox has made a public commitment to opening up > the source code for the voice component of the Second Life viewer. I'm > not in a great position to say more about this, but I'd encourage you to > join their list and discuss. > > Rob > > On 9/4/08 12:26 PM, Harold Brown wrote: >> Seems in all the talk about SLim and such, this little tidbit of >> information was overlooked. >> >> Vivox Inc., the market leader in voice services for developers of >> online games and virtual worlds, today announced the availability >> of the Vivox Open Initiative. By opening its code and network, the >> Vivox Open Initiative will expand the reach of communications in >> and out of online games and virtual worlds while accelerating the >> development of new and innovative features. >> >> The Vivox Open Initiative will be rolled out in phases. In the >> first phase, launching today, Vivox will provide the object code >> for SL Voice, the Second Life voice chat client. By the end of the >> year, Vivox will open APIs to third party technology providers. >> Soon thereafter, Vivox will open up source code to the client side >> SDK. >> >> >> >> http://www.vivox.com/pressreleases_detail.php?id=37 >> >> http://www.vivox.com/open/ >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From liana at lindenlab.com Thu Sep 4 14:20:13 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Thu Sep 4 14:19:46 2008 Subject: [sldev] Meet the Experts: CMake Message-ID: <48C0510D.9040404@lindenlab.com> And yet another event to announce -- Please join us for a "meet the experts" chat with Bill Hoffman of Kitware, creators of CMake , and Bryan O'Sullivan (Sardonyx Linden), leader of the CMake build system implementation at Linden Lab. Format will be informal Q&A, so bring your CMake questions. When: Open source office hour on11-Sept, 2pm PDT Where: Hippotropolis Theater This will be a voice-enabled event, and Bill and Bryan will be using the spatial voice channel. Best, Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/f45e7657/attachment.htm From seg at haxxed.com Thu Sep 4 15:22:59 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu Sep 4 15:23:09 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: <48C03AB6.3090907@gmail.com> References: <48C03AB6.3090907@gmail.com> Message-ID: <1220566979.4415.146.camel@localhost.localdomain> On Thu, 2008-09-04 at 15:44 -0400, Jason Giglio wrote: > I mean, it's a step in the right direction in theory, but I'm not sure > what we are supposed to do with this. Practically speaking, it's hollow PR fluff until the source code is in our hands. With an acceptable license. And don't forget, simply opening the source code does not address the patent license issues with the Siren14 codec. I doubt the codec source is subject to being open sourced anyway, as ViVox is probably getting binaries from Polycom. So ultimately, this does absolutely nothing to help get SLVoice into distributions such as Fedora. (I'll let Robin speak for Debian.) Only a liberal patent license to Siren14 or a switch to Speex can do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080904/83f4da76/attachment.pgp From danteferret at gmail.com Thu Sep 4 17:22:14 2008 From: danteferret at gmail.com (Dante Tucker) Date: Thu Sep 4 17:22:17 2008 Subject: [sldev] Newbie questions about a binary In-Reply-To: References: Message-ID: <4d211a610809041722r709d2848vc4b8f5c1efd2fc5b@mail.gmail.com> I believe ReleaseForDownload is the proper configuration to use. been awhile since I built one though. On Thu, Sep 4, 2008 at 3:28 PM, Vector Hastings wrote: > I've just succeeded in getting a binary out of the old windows path, using > MSVS 2005 Express. > > I performed all the steps in > http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 > including the optional removals at the end. > > I have two questions right off (and they may be related). > > 1. My new program runs an external console window. I think this is the one > turned off with Advanced>Console Window. But even though I turn it off and > restart the program, it starts back up with it showing. > > 2. My new binary is 30% larger than the distributed one. 20,352 KB vs. > 15,700 KB. It's compiled from the > linden\indra\intra_complete\indra_complete.sln solution, using the Release > configuration. (ReleaseNoOpt is the only other configuration that compiles > for me, and it's even larger.) > > > Neither by itself is a terrible problem, but they may bespeak things which > are problems (particularly performance, since the binary is larger. > > Any insight? I'm very newb to this environment, so anything is helpful. > > Thanks to all. > > Vector > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080904/447794ad/attachment.htm From secondloop at gmail.com Thu Sep 4 18:11:04 2008 From: secondloop at gmail.com (azdel slade) Date: Thu Sep 4 18:11:08 2008 Subject: [sldev] Question about setPerspective and stereoscopic mode Message-ID: <1e0ce1090809041811o672c5384r83f87bf6e99b69a4@mail.gmail.com> I think I've narrowed down to the main part of the code to support active stereo (if the comments that saving color masks are only for anaglyph are correct), which I'm trying to get to work with my HMD before I add in the anaglyph code. So, here's my question, which I hope you can help with. In this function, setPerspective, I can't tell if gl_perspective should be called or not. If not, I don't know how to update proj_mat. I put in the rest of the code, so it compiles, I just don't think it works, and I've never written gl code before so I'm not sure. Can you look at it and see what you think needs to be done with proj_mat? The current source from SL is here: https://svn.secondlife.com/svn/linden/branches/maint-render-8/indra/newview/llviewercamera.cpp The patch I'm trying to apply, which is from an older version of the source is here: http://jira.secondlife.com/secure/attachment/13272/dg_stereoscopic.patch And my version of the new source, with the patches applied, is attached. I have a simple version of the preference code and am setting the window to stereo, but I figure I should wait to send a patch until this part works. Thanks! azdel slade -------------- next part -------------- /** * @file llviewercamera.cpp * @brief LLViewerCamera class implementation * * $LicenseInfo:firstyear=2002&license=viewergpl$ * * Copyright (c) 2002-2008, Linden Research, Inc. * * Second Life Viewer Source Code * The source code in this file ("Source Code") is provided by Linden Lab * to you under the terms of the GNU General Public License, version 2.0 * ("GPL"), unless you have obtained a separate licensing agreement * ("Other License"), formally executed by you and Linden Lab. Terms of * the GPL can be found in doc/GPL-license.txt in this distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/gplv2 * * There are special exceptions to the terms and conditions of the GPL as * it is applied to this Source Code. View the full text of the exception * in the file doc/FLOSS-exception.txt in this software distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/flossexception * * By copying, modifying or distributing this software, you acknowledge * that you have read and understood your obligations described above, * and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ #include "llviewerprecompiledheaders.h" #include "llviewercamera.h" #include // for setprecision #include "llquaternion.h" #include "llagent.h" #include "llviewercontrol.h" #include "lldrawable.h" #include "llface.h" #include "llgl.h" #include "llglheaders.h" #include "llviewerobjectlist.h" #include "llviewerregion.h" #include "llviewerwindow.h" #include "llvovolume.h" #include "llworld.h" #include "lltoolmgr.h" #include "llviewerjoystick.h" //glu pick matrix implementation borrowed from Mesa3D glh::matrix4f gl_pick_matrix(GLfloat x, GLfloat y, GLfloat width, GLfloat height, GLint* viewport) { GLfloat m[16]; GLfloat sx, sy; GLfloat tx, ty; sx = viewport[2] / width; sy = viewport[3] / height; tx = (viewport[2] + 2.f * (viewport[0] - x)) / width; ty = (viewport[3] + 2.f * (viewport[1] - y)) / height; #define M(row,col) m[col*4+row] M(0,0) = sx; M(0,1) = 0.f; M(0,2) = 0.f; M(0,3) = tx; M(1,0) = 0.f; M(1,1) = sy; M(1,2) = 0.f; M(1,3) = ty; M(2,0) = 0.f; M(2,1) = 0.f; M(2,2) = 1.f; M(2,3) = 0.f; M(3,0) = 0.f; M(3,1) = 0.f; M(3,2) = 0.f; M(3,3) = 1.f; #undef M return glh::matrix4f(m); } glh::matrix4f gl_perspective(GLfloat fovy, GLfloat aspect, GLfloat zNear, GLfloat zFar) { GLfloat f = 1.f/tanf(DEG_TO_RAD*fovy/2.f); return glh::matrix4f(f/aspect, 0, 0, 0, 0, f, 0, 0, 0, 0, (zFar+zNear)/(zNear-zFar), (2.f*zFar*zNear)/(zNear-zFar), 0, 0, -1.f, 0); } LLViewerCamera::LLViewerCamera() : LLCamera() { calcProjection(getFar()); mCameraFOVDefault = DEFAULT_FIELD_OF_VIEW; mPixelMeterRatio = 0.f; mScreenPixelArea = 0; mZoomFactor = 1.f; mZoomSubregion = 1; } void LLViewerCamera::updateCameraLocation(const LLVector3 ¢er, const LLVector3 &up_direction, const LLVector3 &point_of_interest) { // do not update if we are in build mode AND avatar didn't move if (LLToolMgr::getInstance()->inBuildMode() && !LLViewerJoystick::getInstance()->getCameraNeedsUpdate()) { return; } LLVector3 last_position; LLVector3 last_axis; last_position = getOrigin(); last_axis = getAtAxis(); mLastPointOfInterest = point_of_interest; // constrain to max distance from avatar LLVector3 camera_offset = center - gAgent.getPositionAgent(); LLViewerRegion * regp = gAgent.getRegion(); F32 water_height = (NULL != regp) ? regp->getWaterHeight() : 0.f; LLVector3 origin = center; if (origin.mV[2] > water_height) { origin.mV[2] = llmax(origin.mV[2], water_height+0.20f); } else { origin.mV[2] = llmin(origin.mV[2], water_height-0.20f); } setOriginAndLookAt(origin, up_direction, point_of_interest); F32 dpos = (center - last_position).magVec(); LLQuaternion rotation; rotation.shortestArc(last_axis, getAtAxis()); F32 x, y, z; F32 drot; rotation.getAngleAxis(&drot, &x, &y, &z); mVelocityStat.addValue(dpos); mAngularVelocityStat.addValue(drot); // update pixel meter ratio using default fov, not modified one mPixelMeterRatio = mViewHeightInPixels / (2.f*tanf(mCameraFOVDefault*0.5)); // update screen pixel area mScreenPixelArea =(S32)((F32)mViewHeightInPixels * ((F32)mViewHeightInPixels * mAspect)); } const LLMatrix4 &LLViewerCamera::getProjection() const { calcProjection(getFar()); return mProjectionMatrix; } const LLMatrix4 &LLViewerCamera::getModelview() const { LLMatrix4 cfr(OGL_TO_CFR_ROTATION); getMatrixToLocal(mModelviewMatrix); mModelviewMatrix *= cfr; return mModelviewMatrix; } void LLViewerCamera::calcProjection(const F32 far_distance) const { F32 fov_y, z_far, z_near, f, aspect; fov_y = getView(); z_far = far_distance; z_near = getNear(); aspect = getAspect(); f = 1/tan(fov_y*0.5f); mProjectionMatrix.setZero(); mProjectionMatrix.mMatrix[0][0] = f/aspect; mProjectionMatrix.mMatrix[1][1] = f; mProjectionMatrix.mMatrix[2][2] = (z_far + z_near)/(z_near - z_far); mProjectionMatrix.mMatrix[3][2] = (2*z_far*z_near)/(z_near - z_far); mProjectionMatrix.mMatrix[2][3] = -1; } // Sets up opengl state for 3D drawing. If for selection, also // sets up a pick matrix. x and y are ignored if for_selection is false. // The picking region is centered on x,y and has the specified width and // height. //static void LLViewerCamera::updateFrustumPlanes(LLCamera& camera, BOOL ortho, BOOL zflip) { GLint* viewport = (GLint*) gGLViewport; GLdouble* model = gGLModelView; GLdouble* proj = gGLProjection; GLdouble objX,objY,objZ; LLVector3 frust[8]; if (zflip) { gluUnProject(viewport[0],viewport[1]+viewport[3],0,model,proj,viewport,&objX,&objY,&objZ); frust[0].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1]+viewport[3],0,model,proj,viewport,&objX,&objY,&objZ); frust[1].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1],0,model,proj,viewport,&objX,&objY,&objZ); frust[2].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0],viewport[1],0,model,proj,viewport,&objX,&objY,&objZ); frust[3].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0],viewport[1]+viewport[3],1,model,proj,viewport,&objX,&objY,&objZ); frust[4].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1]+viewport[3],1,model,proj,viewport,&objX,&objY,&objZ); frust[5].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1],1,model,proj,viewport,&objX,&objY,&objZ); frust[6].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0],viewport[1],1,model,proj,viewport,&objX,&objY,&objZ); frust[7].setVec((F32)objX,(F32)objY,(F32)objZ); for (U32 i = 0; i < 4; i++) { frust[i+4] = frust[i+4]-frust[i]; frust[i+4].normVec(); frust[i+4] = frust[i] + frust[i+4]*camera.getFar(); } } else { gluUnProject(viewport[0],viewport[1],0,model,proj,viewport,&objX,&objY,&objZ); frust[0].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1],0,model,proj,viewport,&objX,&objY,&objZ); frust[1].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0]+viewport[2],viewport[1]+viewport[3],0,model,proj,viewport,&objX,&objY,&objZ); frust[2].setVec((F32)objX,(F32)objY,(F32)objZ); gluUnProject(viewport[0],viewport[1]+viewport[3],0,model,proj,viewport,&objX,&objY,&objZ); frust[3].setVec((F32)objX,(F32)objY,(F32)objZ); if (ortho) { LLVector3 far_shift = LLVector3(camera.getFar()*2.0f,0,0); for (U32 i = 0; i < 4; i++) { frust[i+4] = frust[i] + far_shift; } } else { for (U32 i = 0; i < 4; i++) { LLVector3 vec = frust[i] - camera.getOrigin(); vec.normVec(); frust[i+4] = camera.getOrigin() + vec*camera.getFar(); } } } camera.calcAgentFrustumPlanes(frust); } void LLViewerCamera::setPerspective(BOOL for_selection, S32 x, S32 y_from_bot, S32 width, S32 height, BOOL limit_select_distance, F32 z_near, F32 z_far) { //********* UMICH 3D LAB c/o AS ********** F32 fov_y;//, aspect; //********* UMICH 3D LAB c/o AS ********** fov_y = RAD_TO_DEG * getView(); BOOL z_default_near, z_default_far = FALSE; if (z_far <= 0) { z_default_far = TRUE; z_far = getFar(); } if (z_near <= 0) { z_default_near = TRUE; z_near = getNear(); } //********* UMICH 3D LAB c/o AS ********** //aspect = getAspect(); //********* UMICH 3D LAB c/o AS ********** // Load camera view matrix glMatrixMode( GL_PROJECTION ); glLoadIdentity(); glh::matrix4f proj_mat; if (for_selection) { // make a tiny little viewport // anything drawn into this viewport will be "selected" GLint* viewport = (GLint*) gGLViewport; proj_mat = gl_pick_matrix(x+width/2.f, y_from_bot+height/2.f, (GLfloat) width, (GLfloat) height, viewport); if (limit_select_distance) { // ...select distance from control z_far = gSavedSettings.getF32("MaxSelectDistance"); } else { z_far = gAgent.mDrawDistance; } } else { // Only override the far clip if it's not passed in explicitly. if (z_default_far) { z_far = MAX_FAR_CLIP; } glViewport(x, y_from_bot, width, height); gGLViewport[0] = x; gGLViewport[1] = y_from_bot; gGLViewport[2] = width; gGLViewport[3] = height; } if (mZoomFactor > 1.f) { float offset = mZoomFactor - 1.f; int pos_y = mZoomSubregion / llceil(mZoomFactor); int pos_x = mZoomSubregion - (pos_y*llceil(mZoomFactor)); glh::matrix4f translate; translate.set_translate(glh::vec3f(offset - (F32)pos_x * 2.f, offset - (F32)pos_y * 2.f, 0.f)); glh::matrix4f scale; scale.set_scale(glh::vec3f(mZoomFactor, mZoomFactor, 1.f)); proj_mat = scale*proj_mat; proj_mat = translate*proj_mat; } //********* UMICH 3D LAB ********** c/o AS //calcProjection(z_far); // Update the projection matrix cache //proj_mat *= gl_perspective(fov_y,aspect,z_near,z_far); //old code //gluPerspective(fov_y, // aspect, // z_near, // z_far); // compute the frustum planes for a better stereo effect F32 eye_separation = 0.065; //hard coded for now! gSavedSettings.getF32("StereoEyeSeparation"); F32 focal_distance = 6.0; //hard coded for now! gSavedSettings.getF32("StereoFocalDistance"); const float aspect = (float)width / (float)height; const float rads = 0.01745329251994329577f * (fov_y * .5f); const float wd2 = z_near * tan(rads); const float ndfl = z_near / focal_distance; // define frustum float left = -(aspect * wd2) + (eye_separation/2 * ndfl); float right = (aspect * wd2) + (eye_separation/2 * ndfl); float top = wd2; float bottom = -wd2; glFrustum(left, right, bottom, top, z_near, z_far); //********* UMICH 3D LAB ********** //AS - how to update proj_mat? and does glFrustum call suffice? glLoadMatrixf(proj_mat.m); for (U32 i = 0; i < 16; i++) { gGLProjection[i] = proj_mat.m[i]; } glMatrixMode( GL_MODELVIEW ); glh::matrix4f modelview((GLfloat*) OGL_TO_CFR_ROTATION); GLfloat ogl_matrix[16]; getOpenGLTransform(ogl_matrix); modelview *= glh::matrix4f(ogl_matrix); glLoadMatrixf(modelview.m); if (for_selection && (width > 1 || height > 1)) { calculateFrustumPlanesFromWindow((F32)(x - width / 2) / (F32)gViewerWindow->getWindowWidth() - 0.5f, (F32)(y_from_bot - height / 2) / (F32)gViewerWindow->getWindowHeight() - 0.5f, (F32)(x + width / 2) / (F32)gViewerWindow->getWindowWidth() - 0.5f, (F32)(y_from_bot + height / 2) / (F32)gViewerWindow->getWindowHeight() - 0.5f); } // if not picking and not doing a snapshot, cache various GL matrices if (!for_selection && mZoomFactor == 1.f) { // Save GL matrices for access elsewhere in code, especially project_world_to_screen //glGetDoublev(GL_MODELVIEW_MATRIX, gGLModelView); for (U32 i = 0; i < 16; i++) { gGLModelView[i] = modelview.m[i]; } } updateFrustumPlanes(*this); if (gSavedSettings.getBOOL("CameraOffset")) { glMatrixMode(GL_PROJECTION); glTranslatef(0,0,-50); glRotatef(20.0,1,0,0); glMatrixMode(GL_MODELVIEW); } } // Uses the last GL matrices set in set_perspective to project a point from // screen coordinates to the agent's region. void LLViewerCamera::projectScreenToPosAgent(const S32 screen_x, const S32 screen_y, LLVector3* pos_agent) const { GLdouble x, y, z; gluUnProject( GLdouble(screen_x), GLdouble(screen_y), 0.0, gGLModelView, gGLProjection, (GLint*)gGLViewport, &x, &y, &z ); pos_agent->setVec( (F32)x, (F32)y, (F32)z ); } // Uses the last GL matrices set in set_perspective to project a point from // the agent's region space to screen coordinates. Returns TRUE if point in within // the current window. BOOL LLViewerCamera::projectPosAgentToScreen(const LLVector3 &pos_agent, LLCoordGL &out_point, const BOOL clamp) const { BOOL in_front = TRUE; GLdouble x, y, z; // object's window coords, GL-style LLVector3 dir_to_point = pos_agent - getOrigin(); dir_to_point /= dir_to_point.magVec(); if (dir_to_point * getAtAxis() < 0.f) { if (clamp) { return FALSE; } else { in_front = FALSE; } } if (GL_TRUE == gluProject(pos_agent.mV[VX], pos_agent.mV[VY], pos_agent.mV[VZ], gGLModelView, gGLProjection, (GLint*)gGLViewport, &x, &y, &z)) { // convert screen coordinates to virtual UI coordinates x /= gViewerWindow->getDisplayScale().mV[VX]; y /= gViewerWindow->getDisplayScale().mV[VY]; // should now have the x,y coords of grab_point in screen space const LLRect& window_rect = gViewerWindow->getWindowRect(); // ...sanity check S32 int_x = lltrunc(x); S32 int_y = lltrunc(y); BOOL valid = TRUE; if (clamp) { if (int_x < window_rect.mLeft) { out_point.mX = window_rect.mLeft; valid = FALSE; } else if (int_x > window_rect.mRight) { out_point.mX = window_rect.mRight; valid = FALSE; } else { out_point.mX = int_x; } if (int_y < window_rect.mBottom) { out_point.mY = window_rect.mBottom; valid = FALSE; } else if (int_y > window_rect.mTop) { out_point.mY = window_rect.mTop; valid = FALSE; } else { out_point.mY = int_y; } return valid; } else { out_point.mX = int_x; out_point.mY = int_y; if (int_x < window_rect.mLeft) { valid = FALSE; } else if (int_x > window_rect.mRight) { valid = FALSE; } if (int_y < window_rect.mBottom) { valid = FALSE; } else if (int_y > window_rect.mTop) { valid = FALSE; } return in_front && valid; } } else { return FALSE; } } // Uses the last GL matrices set in set_perspective to project a point from // the agent's region space to the nearest edge in screen coordinates. // Returns TRUE if projection succeeds. BOOL LLViewerCamera::projectPosAgentToScreenEdge(const LLVector3 &pos_agent, LLCoordGL &out_point) const { LLVector3 dir_to_point = pos_agent - getOrigin(); dir_to_point /= dir_to_point.magVec(); BOOL in_front = TRUE; if (dir_to_point * getAtAxis() < 0.f) { in_front = FALSE; } GLdouble x, y, z; // object's window coords, GL-style if (GL_TRUE == gluProject(pos_agent.mV[VX], pos_agent.mV[VY], pos_agent.mV[VZ], gGLModelView, gGLProjection, (GLint*)gGLViewport, &x, &y, &z)) { x /= gViewerWindow->getDisplayScale().mV[VX]; y /= gViewerWindow->getDisplayScale().mV[VY]; // should now have the x,y coords of grab_point in screen space const LLRect& window_rect = gViewerWindow->getVirtualWindowRect(); // ...sanity check S32 int_x = lltrunc(x); S32 int_y = lltrunc(y); // find the center GLdouble center_x = (GLdouble)(0.5f * (window_rect.mLeft + window_rect.mRight)); GLdouble center_y = (GLdouble)(0.5f * (window_rect.mBottom + window_rect.mTop)); if (x == center_x && y == center_y) { // can't project to edge from exact center return FALSE; } // find the line from center to local GLdouble line_x = x - center_x; GLdouble line_y = y - center_y; int_x = lltrunc(center_x); int_y = lltrunc(center_y); if (0.f == line_x) { // the slope of the line is undefined if (line_y > 0.f) { int_y = window_rect.mTop; } else { int_y = window_rect.mBottom; } } else if (0 == window_rect.getWidth()) { // the diagonal slope of the view is undefined if (y < window_rect.mBottom) { int_y = window_rect.mBottom; } else if ( y > window_rect.mTop) { int_y = window_rect.mTop; } } else { F32 line_slope = (F32)(line_y / line_x); F32 rect_slope = ((F32)window_rect.getHeight()) / ((F32)window_rect.getWidth()); if (fabs(line_slope) > rect_slope) { if (line_y < 0.f) { // bottom int_y = window_rect.mBottom; } else { // top int_y = window_rect.mTop; } int_x = lltrunc(((GLdouble)int_y - center_y) / line_slope + center_x); } else if (fabs(line_slope) < rect_slope) { if (line_x < 0.f) { // left int_x = window_rect.mLeft; } else { // right int_x = window_rect.mRight; } int_y = lltrunc(((GLdouble)int_x - center_x) * line_slope + center_y); } else { // exactly parallel ==> push to the corners if (line_x > 0.f) { int_x = window_rect.mRight; } else { int_x = window_rect.mLeft; } if (line_y > 0.0f) { int_y = window_rect.mTop; } else { int_y = window_rect.mBottom; } } } if (!in_front) { int_x = window_rect.mLeft + window_rect.mRight - int_x; int_y = window_rect.mBottom + window_rect.mTop - int_y; } out_point.mX = int_x; out_point.mY = int_y; return TRUE; } return FALSE; } void LLViewerCamera::getPixelVectors(const LLVector3 &pos_agent, LLVector3 &up, LLVector3 &right) { LLVector3 to_vec = pos_agent - getOrigin(); F32 at_dist = to_vec * getAtAxis(); F32 height_meters = at_dist* (F32)tan(getView()/2.f); F32 height_pixels = getViewHeightInPixels()/2.f; F32 pixel_aspect = gViewerWindow->getWindow()->getPixelAspectRatio(); F32 meters_per_pixel = height_meters / height_pixels; up = getUpAxis() * meters_per_pixel * gViewerWindow->getDisplayScale().mV[VY]; right = -1.f * pixel_aspect * meters_per_pixel * getLeftAxis() * gViewerWindow->getDisplayScale().mV[VX]; } LLVector3 LLViewerCamera::roundToPixel(const LLVector3 &pos_agent) { F32 dist = (pos_agent - getOrigin()).magVec(); // Convert to screen space and back, preserving the depth. LLCoordGL screen_point; if (!projectPosAgentToScreen(pos_agent, screen_point, FALSE)) { // Off the screen, just return the original position. return pos_agent; } LLVector3 ray_dir; projectScreenToPosAgent(screen_point.mX, screen_point.mY, &ray_dir); ray_dir -= getOrigin(); ray_dir.normVec(); LLVector3 pos_agent_rounded = getOrigin() + ray_dir*dist; /* LLVector3 pixel_x, pixel_y; getPixelVectors(pos_agent_rounded, pixel_y, pixel_x); pos_agent_rounded += 0.5f*pixel_x, 0.5f*pixel_y; */ return pos_agent_rounded; } BOOL LLViewerCamera::cameraUnderWater() const { return getOrigin().mV[VZ] < gAgent.getRegion()->getWaterHeight(); } BOOL LLViewerCamera::areVertsVisible(LLViewerObject* volumep, BOOL all_verts) { S32 i, num_faces; LLDrawable* drawablep = volumep->mDrawable; if (!drawablep) { return FALSE; } LLVolume* volume = volumep->getVolume(); if (!volume) { return FALSE; } LLVOVolume* vo_volume = (LLVOVolume*) volumep; vo_volume->updateRelativeXform(); LLMatrix4 mat = vo_volume->getRelativeXform(); LLMatrix4 render_mat(vo_volume->getRenderRotation(), LLVector4(vo_volume->getRenderPosition())); num_faces = volume->getNumVolumeFaces(); for (i = 0; i < num_faces; i++) { const LLVolumeFace& face = volume->getVolumeFace(i); for (U32 v = 0; v < face.mVertices.size(); v++) { LLVector4 vec = LLVector4(face.mVertices[v].mPosition) * mat; if (drawablep->isActive()) { vec = vec * render_mat; } BOOL in_frustum = pointInFrustum(LLVector3(vec)) > 0; if ( !in_frustum && all_verts || in_frustum && !all_verts) { return !all_verts; } } } return all_verts; } //**************** UMICH 3D LAB ************** void LLViewerCamera::updateStereoValues() { // get the current camera position to calculate the offsets mCameraTempPosition = this->getOrigin(); // get the last point of iterest to calculate the focal point mStereoLastPOI = mLastPointOfInterest; } void LLViewerCamera::rotateToLeftEye() { // Calculate the new position and focal point for the camera (left eye) F32 eye_separation = 0.065; //gSavedSettings.getF32("StereoEyeSeparation"); F32 focal_distance = 6.0; //gSavedSettings.getF32("StereoFocalDistance"); // Translate camera position of half the distance between the 2 eyes LLVector3 new_pos = mCameraTempPosition + eye_separation/2 * (this->getLeftAxis()); // New Point of Interest LLVector3 dir = mStereoLastPOI - mCameraTempPosition; dir.normVec(); LLVector3 new_poi = mCameraTempPosition + dir * focal_distance; // lookat target this->updateCameraLocation(new_pos, getUpAxis(), new_poi); } void LLViewerCamera::rotateToRightEye() { // Calculate the new position and focal point for the camera (right eye) F32 eye_separation = 0.065; //gSavedSettings.getF32("StereoEyeSeparation"); F32 focal_distance = 6.0; //gSavedSettings.getF32("StereoFocalDistance"); // Translate camera position of half the distance between the 2 eyes LLVector3 new_pos = mCameraTempPosition - eye_separation/2 * (this->getLeftAxis()); // New Point of Interest LLVector3 dir = mStereoLastPOI - mCameraTempPosition; dir.normVec(); LLVector3 new_poi = mCameraTempPosition + dir * focal_distance; // lookat target this->updateCameraLocation(new_pos, getUpAxis(), new_poi); } //*************** UMICH 3D LAB ****************** -------------- next part -------------- /** * @file llviewercamera.h * @brief LLViewerCamera class header file * * $LicenseInfo:firstyear=2002&license=viewergpl$ * * Copyright (c) 2002-2008, Linden Research, Inc. * * Second Life Viewer Source Code * The source code in this file ("Source Code") is provided by Linden Lab * to you under the terms of the GNU General Public License, version 2.0 * ("GPL"), unless you have obtained a separate licensing agreement * ("Other License"), formally executed by you and Linden Lab. Terms of * the GPL can be found in doc/GPL-license.txt in this distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/gplv2 * * There are special exceptions to the terms and conditions of the GPL as * it is applied to this Source Code. View the full text of the exception * in the file doc/FLOSS-exception.txt in this software distribution, or * online at http://secondlifegrid.net/programs/open_source/licensing/flossexception * * By copying, modifying or distributing this software, you acknowledge * that you have read and understood your obligations described above, * and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ #ifndef LL_LLVIEWERCAMERA_H #define LL_LLVIEWERCAMERA_H #include "llcamera.h" #include "lltimer.h" #include "llstat.h" #include "m4math.h" class LLCoordGL; class LLViewerObject; // This rotation matrix moves the default OpenGL reference frame // (-Z at, Y up) to Cory's favorite reference frame (X at, Z up) const F32 OGL_TO_CFR_ROTATION[16] = { 0.f, 0.f, -1.f, 0.f, // -Z becomes X -1.f, 0.f, 0.f, 0.f, // -X becomes Y 0.f, 1.f, 0.f, 0.f, // Y becomes Z 0.f, 0.f, 0.f, 1.f }; const BOOL FOR_SELECTION = TRUE; const BOOL NOT_FOR_SELECTION = FALSE; class LLViewerCamera : public LLCamera, public LLSingleton { public: LLViewerCamera(); // const LLVector3 &getPositionAgent() const; // const LLVector3d &getPositionGlobal() const; void updateCameraLocation(const LLVector3 ¢er, const LLVector3 &up_direction, const LLVector3 &point_of_interest); static void updateFrustumPlanes(LLCamera& camera, BOOL ortho = FALSE, BOOL zflip = FALSE); void setPerspective(BOOL for_selection, S32 x, S32 y_from_bot, S32 width, S32 height, BOOL limit_select_distance, F32 z_near = 0, F32 z_far = 0); const LLMatrix4 &getProjection() const; const LLMatrix4 &getModelview() const; // Warning! These assume the current global matrices are correct void projectScreenToPosAgent(const S32 screen_x, const S32 screen_y, LLVector3* pos_agent ) const; BOOL projectPosAgentToScreen(const LLVector3 &pos_agent, LLCoordGL &out_point, const BOOL clamp = TRUE) const; BOOL projectPosAgentToScreenEdge(const LLVector3 &pos_agent, LLCoordGL &out_point) const; LLStat *getVelocityStat() { return &mVelocityStat; } LLStat *getAngularVelocityStat() { return &mAngularVelocityStat; } void getPixelVectors(const LLVector3 &pos_agent, LLVector3 &up, LLVector3 &right); LLVector3 roundToPixel(const LLVector3 &pos_agent); void setDefaultFOV(F32 fov) { mCameraFOVDefault = fov; } F32 getDefaultFOV() { return mCameraFOVDefault; } BOOL cameraUnderWater() const; const LLVector3 &getPointOfInterest() { return mLastPointOfInterest; } BOOL areVertsVisible(LLViewerObject* volumep, BOOL all_verts); F32 getPixelMeterRatio() const { return mPixelMeterRatio; } S32 getScreenPixelArea() const { return mScreenPixelArea; } void setZoomParameters(F32 factor, S16 subregion) { mZoomFactor = factor; mZoomSubregion = subregion; } F32 getZoomFactor() { return mZoomFactor; } S16 getZoomSubRegion() { return mZoomSubregion; } //************ UMICH 3D LAB **************** // Camera Rotations for stereo view void updateStereoValues(); void rotateToLeftEye(); void rotateToRightEye(); //************ UMICH 3D LAB **************** protected: void calcProjection(const F32 far_distance) const; LLStat mVelocityStat; LLStat mAngularVelocityStat; mutable LLMatrix4 mProjectionMatrix; // Cache of perspective matrix mutable LLMatrix4 mModelviewMatrix; F32 mCameraFOVDefault; LLVector3 mLastPointOfInterest; F32 mPixelMeterRatio; // Divide by distance from camera to get pixels per meter at that distance. S32 mScreenPixelArea; // Pixel area of entire window F32 mZoomFactor; S16 mZoomSubregion; //************ UMICH 3D LAB **************** LLVector3 mCameraTempPosition; LLVector3 mStereoLastPOI; //************ UMICH 3D LAB **************** public: }; #endif // LL_LLVIEWERCAMERA_H From tateru.nino at gmail.com Thu Sep 4 20:51:51 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Sep 4 20:52:11 2008 Subject: [sldev] Vivox Opening the source to SLVoice In-Reply-To: References: Message-ID: <48C0ACD7.7020005@weblogsinc.com> Didn't overlook it. "source code to the client side SDK" actually wasn't all that significant - and there's assorted license restrictions and such with the rest. Harold Brown wrote: > Seems in all the talk about SLim and such, this little tidbit of > information was overlooked. > > Vivox Inc., the market leader in voice services for developers of > online games and virtual worlds, today announced the availability > of the Vivox Open Initiative. By opening its code and network, the > Vivox Open Initiative will expand the reach of communications in > and out of online games and virtual worlds while accelerating the > development of new and innovative features. > > The Vivox Open Initiative will be rolled out in phases. In the > first phase, launching today, Vivox will provide the object code > for SL Voice, the Second Life voice chat client. By the end of the > year, Vivox will open APIs to third party technology providers. > Soon thereafter, Vivox will open up source code to the client side > SDK. > > > > http://www.vivox.com/pressreleases_detail.php?id=37 > > http://www.vivox.com/open/ > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://www.massively.com/ From secret.argent at gmail.com Fri Sep 5 05:06:03 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 5 05:05:22 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080806190044.302881139C9@stupor.lindenlab.com> Message-ID: <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> On 2008-09-04, at 10:30, Edward Artaud wrote: > It should be fairly simple to use this same approach to connect to > other IM networks such as Jabber/GTalk if LL is now officially > using this approach to open up IM. The only challenge would be > that some sort of central SL name to (for example) GTalk name > database would need to be maintained. Even simpler than that. They could just provide a jabber server for firstname.lastname@something.secondlife.com. They could have done this a year ago. From tateru.nino at gmail.com Fri Sep 5 05:14:01 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Sep 5 05:14:20 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> Message-ID: <48C12289.70706@weblogsinc.com> The actual work required for jabber connection services to be cross connected in the way SLim has been seems to be roughly the same. Argent Stonecutter wrote: > On 2008-09-04, at 10:30, Edward Artaud wrote: >> It should be fairly simple to use this same approach to connect to >> other IM networks such as Jabber/GTalk if LL is now officially using >> this approach to open up IM. The only challenge would be that some >> sort of central SL name to (for example) GTalk name database would >> need to be maintained. > > Even simpler than that. > > They could just provide a jabber server for > firstname.lastname@something.secondlife.com. > > They could have done this a year ago. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Tateru Nino http://www.massively.com/ From open at autistici.org Fri Sep 5 05:18:16 2008 From: open at autistici.org (Opensource Obscure) Date: Fri Sep 5 05:18:19 2008 Subject: [sldev] Which is the current status of Voice in the Linux viewer? Message-ID: <96c3e7007f0657be87a6e1837d694f04@localhost> Which is the current status of Voice in the Linux viewer? Note: I'm not (yet) a big fan of voice, so my personal experience with this feature is limited. Personally, I'm on Ubuntu 8.04 - Voice here keeps disconnecting: if I'm right this behaviour is known, and it could be Pulseaudio's fault, but what I'm asking here is a general status update, if this is possible. Reading forums and PJIRA reports, it appears to me that Voice isn't yet working out-of-the-box for most Linux users - I'd even say that it never worked in a smooth way. Is this correct? Or is this limited to Ubuntu/Pulseaudio users only? May you suggest a Linux distro where right now SL Voice is just working out-of-the-box? I'm aware that some users managed to get Voice working, but it looks like it always implies tedious workarounds that most users won't get through. Personally, I have fun in tinkering with things, and as I said before I don't miss too much the Voice feature; but I need to point other Linux users to a simple way to get Voice working - this is the reason I'm asking an update about this feature's status. Here are some related PJIRA tickets. 1.19.1.1 TILL 1.20.8 Voice on Linux suddenly crashes http://jira.secondlife.com/browse/VWR-5745 Kicked off voice after exactly 30 seconds when using Linux http://jira.secondlife.com/browse/VWR-5718 (I don't know if this is related to) Public Nightly: No audio in linux (still) http://jira.secondlife.com/browse/VWR-8782 PJIRA search for open tickets about Voice component with 'Linux' in the Summary field, ordered by votes http://bit.ly/2oWePD or http://jira.secondlife.com/secure/IssueNavigator.jspa?reset=true&&pid=10003&query=linux&summary=true&component=10050&status=1&status=3&status=4&sorter/field=votes&sorter/order=DESC Thanks, Opensource Obscure From secret.argent at gmail.com Fri Sep 5 05:30:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 5 05:30:00 2008 Subject: [sldev] Anarchy online in-game web page exploit... Message-ID: <25F84CFF-0D53-45B9-976A-27B908F14D14@gmail.com> While I'm sure the SL open source client has more eyes looking at it than the AO closed source one, this is still worth keeping an eye on: http://securityevaluators.com//content/anarchyonline.jsp From chess at us.ibm.com Fri Sep 5 06:59:28 2008 From: chess at us.ibm.com (David M Chess) Date: Fri Sep 5 06:59:33 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080904190118.DD732113A86@stupor.lindenlab.com> Message-ID: > From: "Edward Artaud" > One question I'd ask is does the announcement of SLim and it's mechanism for > integration mean that it's not necessary for chat in the future to use OGP? > My understanding is that the SLim integration is connecting you to a > separate IM network (the Vivox one) in parallel to your connection to the > grid. It should be fairly simple to use this same approach to connect to > other IM networks such as Jabber/GTalk if LL is now officially using this > approach to open up IM. The only challenge would be that some sort of > central SL name to (for example) GTalk name database would need to be > maintained. If chat integration can occur purely at the viewer level > without all the attendent headaches of going though the grid, then it would > seem such work could happen fairly quickly, which is undoubtedly why LL is > now using this approach with it's newly announced features. There's now some more design strawman stuff for OGP IM in the Wiki; see the "simple design example" section on "https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP". And (although it's still just a strawman) it basically says pretty much what you're suggesting, for Vivox or IRC or GTalk or whatever: that OGP only needs to provide enough protocol for the viewer to correctly connect to the IM subsystem, and the chat itself doesn't need to flow over OGP. This seems rather sensible to me at first blush: there are enough chat protocols out there that it doesn't seem necessary to embed one into OGP; and on the other hand the intragrid does have some requirements that ordinary chat doesn't (like securely associating a chat username with a grid username), so OGP does have a non-trivial role in enabling it. But this is all still very young thinking, and thoughts and contributions from all parties are eagerly sought. (Don't let the fact that the Wiki page is in my userspace keep you from contributing; it's only there because I was foolish enough to volunteer to create the page. I don't consider myself by any means the Sole Expert on the topic. Dive right in!) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080905/b42bc058/attachment.htm From gareth at litesim.com Fri Sep 5 07:35:57 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Sep 5 07:36:01 2008 Subject: [sldev] Anarchy online in-game web page exploit... In-Reply-To: <25F84CFF-0D53-45B9-976A-27B908F14D14@gmail.com> References: <25F84CFF-0D53-45B9-976A-27B908F14D14@gmail.com> Message-ID: <61dbdd7d0809050735r53cad444p79cdccaefa201c7b@mail.gmail.com> http://securityevaluators.com//content/secondlife.jsp On Fri, Sep 5, 2008 at 1:30 PM, Argent Stonecutter wrote: > While I'm sure the SL open source client has more eyes looking at it than > the AO closed source one, this is still worth keeping an eye on: > > http://securityevaluators.com//content/anarchyonline.jsp > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From bos at lindenlab.com Fri Sep 5 10:45:45 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Sep 5 10:45:57 2008 Subject: [sldev] [VWR] Cmake standalone build issues In-Reply-To: References: <48B952E0.2030804@gmail.com> Message-ID: On Thu, Sep 4, 2008 at 2:04 AM, Robin Cornelius wrote: > http://jira.secondlife.com/browse/VWR-8889 > > Patch attached to that one that I am currently using in my packaging. > I've applied a small tweak to that patch, thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080905/7c5db82f/attachment-0001.htm From lenglish5 at cox.net Fri Sep 5 21:37:58 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 5 21:38:00 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <48C20926.4030506@cox.net> David M Chess wrote: > > > From: "Edward Artaud" > > > One question I'd ask is does the announcement of SLim and it's > mechanism for > > integration mean that it's not necessary for chat in the future to > use OGP? > > My understanding is that the SLim integration is connecting you to a > > separate IM network (the Vivox one) in parallel to your connection > to the > > grid. It should be fairly simple to use this same approach to > connect to > > other IM networks such as Jabber/GTalk if LL is now officially using > this > > approach to open up IM. The only challenge would be that some sort of > > central SL name to (for example) GTalk name database would need to be > > maintained. If chat integration can occur purely at the viewer level > > without all the attendent headaches of going though the grid, then > it would > > seem such work could happen fairly quickly, which is undoubtedly why > LL is > > now using this approach with it's newly announced features. > > There's now some more design strawman stuff for OGP IM in the Wiki; > see the "simple design example" section on > "https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP > ". > And (although it's still just a strawman) it basically says pretty > much what you're suggesting, for Vivox or IRC or GTalk or whatever: > that OGP only needs to provide enough protocol for the viewer to > correctly connect to the IM subsystem, and the chat itself doesn't > need to flow over OGP. > > This seems rather sensible to me at first blush: there are enough chat > protocols out there that it doesn't seem necessary to embed one into > OGP; and on the other hand the intragrid does have some requirements > that ordinary chat doesn't (like securely associating a chat username > with a grid username), so OGP does have a non-trivial role in enabling > it. But this is all still very young thinking, and thoughts and > contributions from all parties are eagerly sought. (Don't let the > fact that the Wiki page is in my userspace keep you from contributing; > it's only there because I was foolish enough to volunteer to create > the page. I don't consider myself by any means the Sole Expert on the > topic. Dive right in!) > I don't know what the details are, but both Zha and Zero claim that no existing chat system quite fits the use cases for SL-style chat. I'm pushing to implement regular SL chat in the OGP for now with the AD acting as a relay, so 1) we can have a sense of community in the OGP and 2) we can see what actually happens to the current system in an intergrid/AD world. Lawson From secret.argent at gmail.com Sat Sep 6 05:15:41 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 6 05:14:58 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C12289.70706@weblogsinc.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> Message-ID: <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> On 2008-09-05, at 07:14, Tateru Nino wrote: > The actual work required for jabber connection services to be cross > connected in the way SLim has been seems to be roughly the same. And about the same as "cross connecting" secondlife.com.account and Second Life. They've already *done* that work. They're not even connecting SLim into the Second life Instant Message protocol, which gateway also already exists for IM to Email, they're adding new code to the client to run SLim instead. The only reason they didn't, that I can see, is that it wouldn't get them Voice integration. From secret.argent at gmail.com Sat Sep 6 05:30:49 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 6 05:30:06 2008 Subject: [sldev] Anarchy online in-game web page exploit... In-Reply-To: <61dbdd7d0809050735r53cad444p79cdccaefa201c7b@mail.gmail.com> References: <25F84CFF-0D53-45B9-976A-27B908F14D14@gmail.com> <61dbdd7d0809050735r53cad444p79cdccaefa201c7b@mail.gmail.com> Message-ID: On 2008-09-05, at 09:35, Gareth Nelson wrote: > http://securityevaluators.com//content/secondlife.jsp One of many reasons I don't run streaming video in SL. But you don't need streaming video in SL... there's no essential functionality in streaming video, and just using it opens you up to a known privacy exploit that SL finally provided mitigation for only recently. My point in bringing this up is to reinforce the warning that complex subsystems like this (and Gecko is a much more complex subsystem than Quicktime) bring a risk with them. There are three flaws in Anarchy Online's HTML wrapper exposed by this attack. (1) A buffer overflow attack using pre-positioned data. (2) their wrapping around the HTML control does not stop parent directory traversal attacks. That means that the buffer overflow attack isn't even necessary... if you can direct the HTML control to any location in the system you can get it to run ActiveX controls lin the local computer security zone, which bypasses all restrictions in the HTML control. (3) They are using the Internet Explorer browser component rather than an open source one, which means that there are fewer eyes on the source code (it's interesting to note that Quicktime is also a closed source component), and they're exposed (as noted in point 2) to all the deep and unfixable vulnerabilities in the "security zones" model. For Second Life, the third flaws doesn't exist, but the first is still a possibility, and while it's easier to close down attacks by modifying Gecko than filtering the HTML code fed to the Microsoft HTML control it's still a very large, complex, and (from my own examination of the code when tracking down a proxy bug in it a few years back) poorly documented and poorly factored package. From teravus at gmail.com Sat Sep 6 09:59:20 2008 From: teravus at gmail.com (Teravus Ovares) Date: Sat Sep 6 09:59:21 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> Message-ID: <34cc66250809060959v10a0bca6r125f9cd617c40c4d@mail.gmail.com> A long long time ago, I created the following diagram of how XMPP could work.. http://opensimulator.org/images/1/1c/Proposed_IM_Flow.jpg To sum it up.. an XMPP server with each region serving as an XMPP over BOSH gateway.. with a few tricks to support the legacy protocol and 3D space management using the 'resource'. Mind you, one of the odd things is each simulator consumes and takes on certain aspects of messaging that an XMPP client normally would... like keeping track of presence.. and in the current model, it has to start at the login server.. and filter to all of the appropriate regions that friends are in and get those regions the presence update.. and then those regions are responsible for updating the users appropriately. There are little nuances that make direct transition to XMPP more challenging then just switching. Best Regards Teravus On 9/6/08, Argent Stonecutter wrote: > > On 2008-09-05, at 07:14, Tateru Nino wrote: > >> The actual work required for jabber connection services to be cross >> connected in the way SLim has been seems to be roughly the same. >> > > And about the same as "cross connecting" secondlife.com.account and Second > Life. They've already *done* that work. They're not even connecting SLim > into the Second life Instant Message protocol, which gateway also already > exists for IM to Email, they're adding new code to the client to run SLim > instead. > > The only reason they didn't, that I can see, is that it wouldn't get them > Voice integration. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080906/62d49bbb/attachment.htm From gareth at litesim.com Sat Sep 6 09:59:55 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sat Sep 6 10:00:00 2008 Subject: [sldev] My newest project....... Message-ID: <61dbdd7d0809060959m2dedd3f1ne6ad2b7864abb329@mail.gmail.com> Here's the viewer in a firefox tab (see attached video) -------------- next part -------------- A non-text attachment was scrubbed... Name: secondlife_firefox.ogg Type: application/ogg Size: 964882 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080906/1c35dd4c/secondlife_firefox-0001.ogg From secret.argent at gmail.com Sat Sep 6 11:23:27 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 6 11:22:44 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> Message-ID: <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> On 2008-09-06, at 11:56, Teravus Ovares wrote: > There are little nuances that make direct transition to XMPP more > challenging then just switching. Agreed, but... and this is the important things... this has nothing to do with *switching* to XMPP. They aren't *switching* to SLim, they are simply using the Vivox software in parallel, embedded in the SL client. I'm talking about providing that kind of XMPP gateway, of the same kind as the Vivox gateway that they have implemented. From lenglish5 at cox.net Sat Sep 6 13:25:20 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 6 13:25:23 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> Message-ID: <48C2E730.5040805@cox.net> Argent Stonecutter wrote: > On 2008-09-06, at 11:56, Teravus Ovares wrote: >> There are little nuances that make direct transition to XMPP more >> challenging then just switching. > > Agreed, but... and this is the important things... this has nothing to > do with *switching* to XMPP. They aren't *switching* to SLim, they are > simply using the Vivox software in parallel, embedded in the SL client. > > I'm talking about providing that kind of XMPP gateway, of the same > kind as the Vivox gateway that they have implemented. > All of this will become MUCH easier once OGP is further along. IOW, the faster OGP is debugged and implemented in beta, the faster it can be brought back to the main grid (even if TP isn't enabled, there are plenty of other potential wins with the AD/RD architecture). Lawson (who wouldn't mind a few more eyes on the pyogp also) From edward.artaud at gmail.com Sat Sep 6 14:10:15 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sat Sep 6 14:10:19 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C2E730.5040805@cox.net> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> <48C2E730.5040805@cox.net> Message-ID: On Sat, Sep 6, 2008 at 1:25 PM, Lawson English wrote: > Argent Stonecutter wrote: >> >> I'm talking about providing that kind of XMPP gateway, of the same kind as >> the Vivox gateway that they have implemented. >> > > All of this will become MUCH easier once OGP is further along. IOW, the > faster OGP is debugged and implemented in beta, the faster it can be brought > back to the main grid (even if TP isn't enabled, there are plenty of other > potential wins with the AD/RD architecture). > I'm not sure OGP really has to figure into this. I think the point is that the Vivox integration doesn't seem to use OGP, which implies that OGP isn't on the critical path to getting an XMPP gateway implemented the same way. Since the idea of parallel chat networks seems to be officially blessed, it would be good to take it the small incremental step to add XMPP. Ed From lenglish5 at cox.net Sat Sep 6 14:19:10 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 6 14:19:12 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> <48C2E730.5040805@cox.net> Message-ID: <48C2F3CE.30603@cox.net> Edward Artaud wrote: > On Sat, Sep 6, 2008 at 1:25 PM, Lawson English wrote: > >> Argent Stonecutter wrote: >> >>> I'm talking about providing that kind of XMPP gateway, of the same kind as >>> the Vivox gateway that they have implemented. >>> >>> >> All of this will become MUCH easier once OGP is further along. IOW, the >> faster OGP is debugged and implemented in beta, the faster it can be brought >> back to the main grid (even if TP isn't enabled, there are plenty of other >> potential wins with the AD/RD architecture). >> >> > > I'm not sure OGP really has to figure into this. I think the point is > that the Vivox integration doesn't seem to use OGP, which implies that > OGP isn't on the critical path to getting an XMPP gateway implemented > the same way. Since the idea of parallel chat networks seems to be > officially blessed, it would be good to take it the small incremental > step to add XMPP. > > Well, as I said, it will be MUCH easier to do this kind of thing with the OGP. Agent Domain replaces the simulator for most functions, such as group IM relay. Lawson From chess at us.ibm.com Sat Sep 6 16:50:08 2008 From: chess at us.ibm.com (David M Chess) Date: Sat Sep 6 16:50:16 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C20926.4030506@cox.net> Message-ID: Lawon English wrote: > I don't know what the details are, but both Zha and Zero claim that no > existing chat system quite fits the use cases for SL-style chat. I'm > pushing to implement regular SL chat in the OGP for now with the AD > acting as a relay, so 1) we can have a sense of community in the OGP and > 2) we can see what actually happens to the current system in an > intergrid/AD world. Yep! :) Again, see the Wiki page. Zero has been told by some IRC provider that the typical SL usage pattern (many users essentially in 25 group-chats at all times) would strain their implementation, for instance. This came up in a recent office hours, and I tried to summarize it on the Wiki page. There's a whole (currently empty) section of the Wiki page just waiting for a design that does what you say: taking current SL chat and using the AD as a relay. Please don't hesitate to write your ideas there: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#Using_the_AD_as_a_simple_relay That number again https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP :) Dale Innis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080906/7151839a/attachment.htm From edward.artaud at gmail.com Sat Sep 6 17:22:23 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sat Sep 6 17:22:26 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> Message-ID: Clearly there's some change in roadmap implied by the introduction of SLim that these OGP plans aren't taking into consideration. On Sat, Sep 6, 2008 at 4:50 PM, David M Chess wrote: > > Lawon English wrote: > >> I don't know what the details are, but both Zha and Zero claim that no >> existing chat system quite fits the use cases for SL-style chat. I'm >> pushing to implement regular SL chat in the OGP for now with the AD >> acting as a relay, so 1) we can have a sense of community in the OGP and >> 2) we can see what actually happens to the current system in an >> intergrid/AD world. > > Yep! :) Again, see the Wiki page. Zero has been told by some IRC provider > that the typical SL usage pattern (many users essentially in 25 group-chats > at all times) would strain their implementation, for instance. This came up > in a recent office hours, and I tried to summarize it on the Wiki page. From hakushakukun at gmail.com Sat Sep 6 17:30:14 2008 From: hakushakukun at gmail.com (Adric R) Date: Sat Sep 6 17:30:17 2008 Subject: [sldev] Introducing the Imprudence Project Message-ID: <781e4b420809061730g4cc6a37td56008458cfec56e@mail.gmail.com> As some of you might have read recently on massively ( http://www.massively.com/2008/09/02/imprudence-for-second-life/), Jacek Antonelli and myself, along with other interested members of the community, have launched a new viewer project designed specifically to address usability in the Second Life viewer: Imprudence. Imprudence is an opensource viewer fork for SL, and the general open grid. As an independent viewer, we have more freedom to innovate than LL does to make usability changes. Where they are conservative, we can be bold and take chances, try new things. The hope is that good ideas will flow back and forth between Imprudence and the linden viewer, making the SL experience better for all. Right now, we are gathering input on our forums and mailing list as well as considering patches for our first release. If you're interested in contributing, or you simply want to follow along and learn more about the project, I encourage you to head to http://www.imprudenceviewer.org and join in the discussions currently going on. We are looking for a wide range of contributors from across the spectrum of the community to give their input, not just programmers. In other words: Have an issue with viewer that you absolutely long to improve? Let us know. Have a UI idea but don't know how to present it? We'll help you. Have a patch that you doubt LL will take? We want it. You're not a code monkey, but you're interested in usability, UI design, or just making using SL a better experience? Our minds and ears are open. The broader our opinion base, the better the project becomes. Our goal is to make the viewer more usable for everybody (accessibility features are also high on our list). I know to some, the case for usability might be seen as "quibbling over details", but both Jacek and myself, as well as others, consider usability an essential component to good software. (Interest in other projects like Dusan Writer's UI contest shows a clear demand, for example). In summary: - Imprudence is new opensource viewer for SL and the open grid, focusing on usability. - Contributions are welcome, encouraged. - Imprudence is a project for programmers and non-programmers alike. I also recommend reading our Imprudence Manifesto: http://www.imprudenceviewer.org/manifesto/ As well as our list of potential ways to contribute: http://www.imprudenceviewer.org/contribute/ -- Adric AKA McCabe Maxsted inSL(tm) -- "Work is love made visible." ? Kahlil Gibran "We will not walk in fear, one of another. We will not be driven by fear into an age of unreason if we dig deep in our history and doctrine and remember that we are not descended from fearful men, not from men who feared to write, to speak, to associate and to defend causes which were for the moment unpopular. We can deny our heritage and our history, but we cannot escape responsibility for the result. There is no way for a citizen of the Republic to abdicate his responsibility." -- Edward R. Murrow, March 9, 1954 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080906/6d16ef24/attachment.htm From lenglish5 at cox.net Sat Sep 6 20:22:45 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 6 20:22:50 2008 Subject: [sldev] Introducing the Imprudence Project In-Reply-To: <781e4b420809061730g4cc6a37td56008458cfec56e@mail.gmail.com> References: <781e4b420809061730g4cc6a37td56008458cfec56e@mail.gmail.com> Message-ID: <48C34905.1090902@cox.net> Adric R wrote: > As some of you might have read recently on massively > (http://www.massively.com/2008/09/02/imprudence-for-second-life/), > Jacek Antonelli and myself, along with other interested members of the > community, have launched a new viewer project designed specifically to > address usability in the Second Life viewer: Imprudence. > > Imprudence is an opensource viewer fork for SL, and the general open > grid. As an independent viewer, we have more freedom to innovate than > LL does to make usability changes. Where they are conservative, we can > be bold and take chances, try new things. The hope is that good ideas > will flow back and forth between Imprudence and the linden viewer, > making the SL experience better for all. > > Right now, we are gathering input on our forums and mailing list as > well as considering patches for our first release. If you're > interested in contributing, or you simply want to follow along and > learn more about the project, I encourage you to head to > http://www.imprudenceviewer.org and > join in the discussions currently going on. We are looking for a wide > range of contributors from across the spectrum of the community to > give their input, not just programmers. In other words: > > Have an issue with viewer that you absolutely long to improve? Let us > know. > Have a UI idea but don't know how to present it? We'll help you. > Have a patch that you doubt LL will take? We want it. > You're not a code monkey, but you're interested in usability, UI > design, or just making using SL a better experience? Our minds and > ears are open. > > The broader our opinion base, the better the project becomes. Our goal > is to make the viewer more usable for everybody (accessibility > features are also high on our list). > > I know to some, the case for usability might be seen as "quibbling > over details", but both Jacek and myself, as well as others, consider > usability an essential component to good software. (Interest in other > projects like Dusan Writer's UI contest shows a clear demand, for > example). > > In summary: > > - Imprudence is new opensource viewer for SL and the open grid, > focusing on usability. > - Contributions are welcome, encouraged. > - Imprudence is a project for programmers and non-programmers alike. > > I also recommend reading our Imprudence Manifesto: > http://www.imprudenceviewer.org/manifesto/ > > As well as our list of potential ways to contribute: > http://www.imprudenceviewer.org/contribute/ > > -- Adric AKA McCabe Maxsted inSL(tm) > Any pythonistas want to help with pyogp? ;-) Lawson From lenglish5 at cox.net Sat Sep 6 23:10:54 2008 From: lenglish5 at cox.net (Lawson English) Date: Sat Sep 6 23:10:56 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> Message-ID: <48C3706E.7080404@cox.net> Edward Artaud wrote: > Clearly there's some change in roadmap implied by the introduction of > SLim that these OGP plans aren't taking into consideration. > > I don't think so. There's no reason to think that converting the IM part of SLim to the AD/RD model would be any more difficult than converting regular IM or any other current protocol in SL, and good reason to think that the OGP version will be easier to implement than the current version. Afterall, there's a relatively tiny number of Agent Domains that will be involved as compared to the 20K+ sims that the protocols have to deal with now. Even with the full implemnatation of the "scary numbers" of a billion accounts, there will be no more Agent Domains than there are second life simulators, ccurently (assuming 50K avatars per AD). Not that any current design can scale that way, but even so, the implementation for the near future (5 years or so) shouldn't be anything near as wonky as something coordinating the IM from 20,000 sims. Lawson > On Sat, Sep 6, 2008 at 4:50 PM, David M Chess wrote: > >> Lawon English wrote: >> >> >>> I don't know what the details are, but both Zha and Zero claim that no >>> existing chat system quite fits the use cases for SL-style chat. I'm >>> pushing to implement regular SL chat in the OGP for now with the AD >>> acting as a relay, so 1) we can have a sense of community in the OGP and >>> 2) we can see what actually happens to the current system in an >>> intergrid/AD world. >>> >> Yep! :) Again, see the Wiki page. Zero has been told by some IRC provider >> that the typical SL usage pattern (many users essentially in 25 group-chats >> at all times) would strain their implementation, for instance. This came up >> in a recent office hours, and I tried to summarize it on the Wiki page. >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From secret.argent at gmail.com Sun Sep 7 06:47:13 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 7 06:46:35 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C3706E.7080404@cox.net> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> Message-ID: <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> On 2008-09-07, at 01:10, Lawson English wrote: > Edward Artaud wrote: >> Clearly there's some change in roadmap implied by the introduction of >> SLim that these OGP plans aren't taking into consideration. > > I don't think so. There's no reason to think that converting the IM > part of SLim to the AD/RD model would be any more difficult than > converting regular IM or any other current protocol in SL, and good > reason to think that the OGP version will be easier to implement > than the current version. I think what's worth keeping in mind is that some of the requirements (from Linden labs) for messaging seem to have been relaxed: Vivox doesn't appear to provide the difficult group requirement any more than XMPP does, so suddenly satisfying that is no longer important. From joe at lindenlab.com Sun Sep 7 10:05:12 2008 From: joe at lindenlab.com (Joe Miller) Date: Sun Sep 7 10:05:29 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> Message-ID: <48C409C8.6060107@lindenlab.com> Argent Stonecutter wrote: > > I think what's worth keeping in mind is that some of the requirements > (from Linden labs) for messaging seem to have been relaxed: Vivox > doesn't appear to provide the difficult group requirement any more > than XMPP does, so suddenly satisfying that is no longer important. > As I indicated in a blog reply, we did design SLim to support SL group channels and proximal voice channels, both of which are fairly unique communication abstractions for Second Life. And, you'll see support for both in a later release of SLim. As you and others have pointed out, it would be possible to create an XMPP client-side gateway to support external IM systems, but without an easy way to handle large group channels. The standard chosen for the SLim implementation is SIP/SIMPLE. Here are a couple references: http://en.wikipedia.org/wiki/SIMPLE (we use 'page' mode) http://www.cs.helsinki.fi/u/yanev/simplep.pdf In Enterprise/Carrier scale environments Avaya, Alcatel-Lucent and Microsoft have soft/hard clients which use SIP/SIMPLE. Some consumer-level soft clients are Gizmo, Gaim, Linphone, Windows Messenger, Wengo, PingTel (and its descendants). -- joe From liana at lindenlab.com Sun Sep 7 10:13:51 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Sun Sep 7 10:13:52 2008 Subject: [sldev] 2008 Hippo Award winners announced Message-ID: <48C40BCF.5020109@lindenlab.com> Short version on the blog. Long version (well worth reading) on the wiki. Many thanks to all of you for your contributions over the last year, and congrats to the winners! Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080907/9a8e8f59/attachment.htm From secret.argent at gmail.com Sun Sep 7 11:05:53 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 7 11:05:11 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C409C8.6060107@lindenlab.com> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> Message-ID: <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> On 2008-09-07, at 12:05, Joe Miller wrote: > As I indicated in a blog reply, we did design SLim to support SL group > channels and proximal voice channels, both of which are fairly unique > communication abstractions for Second Life. And, you'll see > support for > both in a later release of SLim. As you and others have pointed > out, it > would be possible to create an XMPP client-side gateway to support > external IM systems, but without an easy way to handle large group > channels. Neither group channels nor voice are essential for business in SL. Simple 1:1 communication, to handle customer support, IS essential, and lack of the ability to contact individual customers offline through a simple protocol that can be run through firewalls and proxies has long been a sore point. Does SIM/SIMPLE satisfy that, or is it dependent on a rich IP environment with support for UDP and reverse connections on arbitrary ports? From edward.artaud at gmail.com Sun Sep 7 12:36:20 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sun Sep 7 12:36:25 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> Message-ID: I have to agree with Argent here, the point that this discussion is surfacing is that the need and desire for interoperability with XMPP based chat such as GTalk is generally perceived as being more pressing than the group and proximity use cases, even and especially for business use. I think that there must be some understanding of that at the Lab, which is why SLim was positioned in the way that it was in the blog post. One very simple way of expressing this (as a feature not necessarily in implementation), would be to provide an "Offline IM to GTalk" (or whatever other IM system) feature to complement the "Offline IM to Email" feature. The SIP stuff is nice, but until I can have set Vivox to ring me up on a Cisco 7900 phone on my office desk, I'm not sure it's going to be integrated into the work experience. Ed On Sun, Sep 7, 2008 at 11:05 AM, Argent Stonecutter wrote: > On 2008-09-07, at 12:05, Joe Miller wrote: >> >> As I indicated in a blog reply, we did design SLim to support SL group >> channels and proximal voice channels, both of which are fairly unique >> communication abstractions for Second Life. And, you'll see support for >> both in a later release of SLim. As you and others have pointed out, it >> would be possible to create an XMPP client-side gateway to support >> external IM systems, but without an easy way to handle large group >> channels. > > Neither group channels nor voice are essential for business in SL. Simple > 1:1 communication, to handle customer support, IS essential, and lack of the > ability to contact individual customers offline through a simple protocol > that can be run through firewalls and proxies has long been a sore point. > > Does SIM/SIMPLE satisfy that, or is it dependent on a rich IP environment > with support for UDP and reverse connections on arbitrary ports? > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From tao.takashi at googlemail.com Sun Sep 7 14:01:04 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Sun Sep 7 14:01:07 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> Message-ID: <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> Hi! On Sun, Sep 7, 2008 at 9:36 PM, Edward Artaud wrote: > I have to agree with Argent here, the point that this discussion is > surfacing is that the need and desire for interoperability with XMPP > based chat such as GTalk is generally perceived as being more pressing > than the group and proximity use cases, even and especially for > business use. I think that there must be some understanding of that > at the Lab, which is why SLim was positioned in the way that it was in > the blog post. One very simple way of expressing this (as a feature > not necessarily in implementation), would be to provide an "Offline IM > to GTalk" (or whatever other IM system) feature to complement the > "Offline IM to Email" feature. I also wonder if the group situation will stay that way on the long run with OGP. Right now with only 25 groups you probably need to stay in the big groups to stay connected. If you wouldn't have that requirment and the whole world is more decentralized anyway I wonder if those groups would look different. Additionally if you are more free to join and leave without any hassle (like you might do with IRC channels). Right now with that limit you always have to think plus I think some groups have member restrictions because of the lag (IIRC). But of course we also need to find a solution to support the existing group model with those huge groups. BTW, what are the actual numbers for the bigger ones? So pluggability might be key and the question is how we can support both: Some not so secure environment where you maybe can simply join some non-SL IM system like Jabber or IRC without further identity check and a more secure one like the one we have now where you can be sure that "Tao Takashi@syntronik.de" (imagine this would be my full qualified name in OGP) really is me. Additionally there might be a mix of both but where you can distinguish not verified agents as such. Also I think the IM service should be kept outside the AD but can ask the AD for verification of somebody. So that means you have to trust the IM service to do the authentication and of course the ADs in question to answer it correctly. The details "just" need to be worked out ;-) Another thing I am thinking about is how we can also use service discovery (e.g. by using XRDS-Simple or the successor protocol which is worked on right now) for each person to check which IM service it prefers to be contacted under. -- Tao > > The SIP stuff is nice, but until I can have set Vivox to ring me up on > a Cisco 7900 phone on my office desk, I'm not sure it's going to be > integrated into the work experience. > > Ed > > On Sun, Sep 7, 2008 at 11:05 AM, Argent Stonecutter > wrote: >> On 2008-09-07, at 12:05, Joe Miller wrote: >>> >>> As I indicated in a blog reply, we did design SLim to support SL group >>> channels and proximal voice channels, both of which are fairly unique >>> communication abstractions for Second Life. And, you'll see support for >>> both in a later release of SLim. As you and others have pointed out, it >>> would be possible to create an XMPP client-side gateway to support >>> external IM systems, but without an easy way to handle large group >>> channels. >> >> Neither group channels nor voice are essential for business in SL. Simple >> 1:1 communication, to handle customer support, IS essential, and lack of the >> ability to contact individual customers offline through a simple protocol >> that can be run through firewalls and proxies has long been a sore point. >> >> Does SIM/SIMPLE satisfy that, or is it dependent on a rich IP environment >> with support for UDP and reverse connections on arbitrary ports? >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From edward.artaud at gmail.com Sun Sep 7 14:39:26 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sun Sep 7 14:39:29 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> Message-ID: Having built these types of group chat systems in the past, at a certain point, they tend to move to a pull model of polling a chat history rather than the push message propagation model, so that the client can basically ask the server to deliver to it the new chat events posted since the last poll time. After all, there's a reason why there's a limit to the number of agents you can have in a single region, the problem with groups is that they often have an order of magnitude more members. On Sun, Sep 7, 2008 at 2:01 PM, Christian Scholz / Tao Takashi (SL) wrote: > I also wonder if the group situation will stay that way on the long > run with OGP. Right now with only 25 groups you probably need to stay > in the big groups to stay connected. If you wouldn't have that > requirment and the whole world is more decentralized anyway I wonder > if those groups would look different. Additionally if you are more > free to join and leave without any hassle (like you might do with IRC > channels). Right now with that limit you always have to think plus I > think some groups have member restrictions because of the lag (IIRC). > From kf6kjg at gmail.com Sun Sep 7 17:18:10 2008 From: kf6kjg at gmail.com (Ricky) Date: Sun Sep 7 17:18:13 2008 Subject: [sldev] Which is the current status of Voice in the Linux viewer? In-Reply-To: <96c3e7007f0657be87a6e1837d694f04@localhost> References: <96c3e7007f0657be87a6e1837d694f04@localhost> Message-ID: <3bb9647e0809071718n71f0f74fjed0e6179e30477c4@mail.gmail.com> Took me a long time to find a configuration where I could both hear Voice and SFX... I am feeding the SL SFX through eSounD, and Voice through ALSA. If I log in to a region, then I can hear everyone there, but if I TP, or walk, into a region, then I cannot hear anyone in that region. If someone logs into/TPs into a region after I am logged onto that region, I cannot hear them. If someone I CAN hear teleports out and back, I can no longer hear them. The ONLY case that works is when I log into a region and listen to those who are already there. I have tried to "restart" Voice by going into the configuration panel and causing it to disconnect and re-connect, but that doesn't fix the issue. Only re-logging seems to help. I have used the debug menu to up the Voice debug logging level to 5, but I haven't had time to look at the log files yet. Another problem is that SL can't seem to find my mic... But neither can Skype, and Audacity takes some special handling to find it, so it looks like it might be my config. :P I am running a 64bit dual-core Gentoo box with onboard nVidia MCP55 High Definition Audio. Info from the Sound section of KInfoCenter: Sound Driver: 3.8.1a-980706 (ALSA v1.0.16rc2 emulation code) Kernel: Linux 2.6.25-gentoo-r7 #1 SMP x86_64 Funny thing is, I had to do the same kind of changes, and seem to have the same kind of problems (not tested well enough to be sure,) on my 32bit Alienware 7700 laptop. It's also running Gentoo. It has the Intel ICH6 integrated sound hardware. Ricky Cron Stardust PS: Sorry about the double post Open. Gmail keeps catching me :D On Fri, Sep 5, 2008 at 5:18 AM, Opensource Obscure wrote: > > Which is the current status of Voice in the Linux viewer? > > Note: I'm not (yet) a big fan of voice, so my personal experience > with this feature is limited. > > Personally, I'm on Ubuntu 8.04 - Voice here keeps disconnecting: > if I'm right this behaviour is known, and it could be > Pulseaudio's fault, but what I'm asking here is a general status > update, if this is possible. > > Reading forums and PJIRA reports, it appears to me that Voice > isn't yet working out-of-the-box for most Linux users - I'd > even say that it never worked in a smooth way. Is this correct? > Or is this limited to Ubuntu/Pulseaudio users only? > May you suggest a Linux distro where right now SL Voice is just > working out-of-the-box? > > I'm aware that some users managed to get Voice working, but it > looks like it always implies tedious workarounds that most > users won't get through. > > Personally, I have fun in tinkering with things, and as I said > before I don't miss too much the Voice feature; but I need > to point other Linux users to a simple way to get Voice > working - this is the reason I'm asking an update about > this feature's status. > > Here are some related PJIRA tickets. > > 1.19.1.1 TILL 1.20.8 Voice on Linux suddenly crashes > http://jira.secondlife.com/browse/VWR-5745 > > Kicked off voice after exactly 30 seconds when using Linux > http://jira.secondlife.com/browse/VWR-5718 > > (I don't know if this is related to) > Public Nightly: No audio in linux (still) > http://jira.secondlife.com/browse/VWR-8782 > > PJIRA search for open tickets about Voice component with 'Linux' in the > Summary field, ordered by votes > http://bit.ly/2oWePD or > > http://jira.secondlife.com/secure/IssueNavigator.jspa?reset=true&&pid=10003&query=linux&summary=true&component=10050&status=1&status=3&status=4&sorter/field=votes&sorter/order=DESC > > > Thanks, > Opensource Obscure > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080907/ef387942/attachment.htm From lenglish5 at cox.net Sun Sep 7 18:00:03 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 7 18:00:05 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> Message-ID: <48C47913.6080705@cox.net> Edward Artaud wrote: > Having built these types of group chat systems in the past, at a > certain point, they tend to move to a pull model of polling a chat > history rather than the push message propagation model, so that the > client can basically ask the server to deliver to it the new chat > events posted since the last poll time. After all, there's a reason > why there's a limit to the number of agents you can have in a single > region, the problem with groups is that they often have an order of > magnitude more members. > > On Sun, Sep 7, 2008 at 2:01 PM, Christian Scholz / Tao Takashi (SL) > wrote: > >> I also wonder if the group situation will stay that way on the long >> run with OGP. Right now with only 25 groups you probably need to stay >> in the big groups to stay connected. If you wouldn't have that >> requirment and the whole world is more decentralized anyway I wonder >> if those groups would look different. Additionally if you are more >> free to join and leave without any hassle (like you might do with IRC >> channels). Right now with that limit you always have to think plus I >> think some groups have member restrictions because of the lag (IIRC). >> >> Once pyogp gets to a certain level of maturity, we can start testing massive numbers of accounts for scalability purposes for things like group IM. As it stands now, I think it is obvious that we need to support *at least* the current setup for SL groups within the SL Agent Domain (either that or suddenly change how everyone in the World communicates with each other when the Agent Domain comes online in agni). My conception for the current group IM as it could be done in OGP, is simply to make the Agent Domain responsible for forwarding group messages to individual avies. The IM server tracks membership AND the associated Agent Domain and sends the Agent domain a message for each group with recipients attached (or the AD could request such a list). The AD is responsible for determining if a given recipient is online or not, and forwarding the message to the client or to email or just eating it. Responses to the group IM server are sent directly to the server or they could be collected and forwarded in some way. The idea being that the busywork of keeping track of who just logged on or off is now put on the AD and not the group IM server. Other forms of IM, might go directly to the client via plugins, bypassing the AD completely, or, in the case of ad hoc sessions, an encrypted CAP could be sent from a corporate grid via normal communications through the AD, and decrypted using a key given to the client out-of-band (corporate email) and a direct session of some kind could be set up without the participation of the AD. In any case, arbitrarily deciding to forgo the current SL group IM design is not really an option, as far as I am concerned. The SL community is set up aground the current chat behavior (missing messages and errors aside), and to suddenly change that would be more than a little disruptive. No need to limit ourselves to just the SL model, but to just chuck it out is a big no-no. Lawson From edward.artaud at gmail.com Sun Sep 7 18:14:05 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sun Sep 7 18:14:15 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C47913.6080705@cox.net> References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> <48C47913.6080705@cox.net> Message-ID: On Sun, Sep 7, 2008 at 6:00 PM, Lawson English wrote: > My conception for the current group IM as it could be done in OGP, is simply > to make the Agent Domain responsible for forwarding group messages to > individual avies. Yes, it was exactly my point that in practice this sort of mechanism does not scale for group chat. Group messages should go to directly a group message datastore and the viewer can poll the datastore if they're online to retrieve new messages. Ed From lenglish5 at cox.net Sun Sep 7 19:24:43 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 7 19:24:49 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> <48C3706E.7080404@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> <48C47913.6080705@cox.net> Message-ID: <48C48CEB.9060605@cox.net> Edward Artaud wrote: > On Sun, Sep 7, 2008 at 6:00 PM, Lawson English wrote: > >> My conception for the current group IM as it could be done in OGP, is simply >> to make the Agent Domain responsible for forwarding group messages to >> individual avies. >> > > Yes, it was exactly my point that in practice this sort of mechanism > does not scale for group chat. Group messages should go to directly a > group message datastore and the viewer can poll the datastore if > they're online to retrieve new messages. > > Ed > _______________________________________________ > > How is group membership determined? Does the datastore contani a list of authorized users? Lawson From AndromedaQuonset at comcast.net Sun Sep 7 20:54:50 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Sun Sep 7 20:54:41 2008 Subject: [sldev] Help compiling Message-ID: <20080908035440.21A0141AFB6@stupor.lindenlab.com> Greetings! I do not have VS2003. I have VS2002, VS2005, VS2008 Express. The one I am _comfortable_ with is VS6.0. I have been attempting to compile the client. What I seem to have accomplished is created a mess. I decided to use VS2005 as the best choice among the compilers I have. The client version I chose was 1.19.1 I am running under Windows XP SP2, 32-bit. I have attempted to download all the myriad of files. I found I needed to upgrade VS2005 to SP1. So, that's done. At one point, under "Configuring for VS2005" http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29, it says "To configure, go into linden\indra and run develop.py -G VC80. This will create a build directory named build-VC80. " I can safely say that there is no "develop.py" in "linden\indra" or anywhere else in the system. Nor can I find out where I might download it from. With that lacking, I've gone to http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 where I have done the conversion manually. I have gotten from over 4,000 errors, to where I only have a few errors. Much of that was from the XML code that was pre-pended inside of the openGL headers. At the moment, I am stuck at "Link : fatal error LNK1104: cannot open file 'dinput8.lib' There are other errors that appear earlier, over 250 of them, but since linking gets invoked, I don't know if they matter or not. One other thing: the wiki says I need to obtain and install something called "Microsoft Windows Server 2003 R2 Platform SDK". This is no longer available. When you jump through all the hoops to download it at the Microsoft site, what happens is you end up on a download site for "Windows SDK for Windows Server 2008 and .NET Framework 3.5". I have gone ahead and downloaded this, however, since it isn't the version specified, I have not installed it. I don't understand, anyway, why I would need this. I'm not running a Windows "server" OS of any flavor here. From edward.artaud at gmail.com Sun Sep 7 21:11:27 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Sun Sep 7 21:11:30 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C48CEB.9060605@cox.net> References: <48C20926.4030506@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> <48C47913.6080705@cox.net> <48C48CEB.9060605@cox.net> Message-ID: Well, ultimately I'd imagine that the group message store and it's associated web service would sit in the Agent Domain. On Sun, Sep 7, 2008 at 7:24 PM, Lawson English wrote: > > How is group membership determined? Does the datastore contani a list of > authorized users? > From lenglish5 at cox.net Sun Sep 7 22:01:08 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 7 22:01:11 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> <0E8ACD2E-3AB4-41D5-8CC7-DCD6D1E9FF48@gmail.com> <48C409C8.6060107@lindenlab.com> <50FAAAED-8C1D-48E4-8A89-66F5DC7B498A@gmail.com> <23bbb49e0809071401k4df010cnf712930eb723ff28@mail.gmail.com> <48C47913.6080705@cox.net> <48C48CEB.9060605@cox.net> Message-ID: <48C4B194.4070006@cox.net> Edward Artaud wrote: > Well, ultimately I'd imagine that the group message store and it's > associated web service would sit in the Agent Domain. > > On Sun, Sep 7, 2008 at 7:24 PM, Lawson English wrote: > >> How is group membership determined? Does the datastore contani a list of >> authorized users? >> >> Problem there is that you now have to have communications between Agent Domains in order to share group IM. Which is fine, but introduces the concept of p2p between Agent Domains, OR you have to have clients associating themselves directly with more than one AD. Lawson From secondloop at gmail.com Sun Sep 7 22:37:28 2008 From: secondloop at gmail.com (azdel slade) Date: Sun Sep 7 22:37:31 2008 Subject: [sldev] cmake compile issues Message-ID: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> Hi, Is an email to this list a useful contribution to the cmake discussion or should I just change the wiki straight out? I'm using VS2005 pro, downloaded from M$ dreamspark. Using the command from the wiki develop.py -G VC80 fails with an error opening SecondLife.sln. Simply running develop.py configures successfully. Also, why is this parentheses: (If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to "linden\libraries\i686-win32\lib\release" and to "linden\libraries\i686-win32\lib\debug") on the page for cmake instructions? curious. Also, I think that the ares and openjpeg instructions should probably be moved into the own section, like "compiling older sources". Since the parentheses are easy to miss. Also, llkdu.dll is still missing and still not in the instructions. Where should I get this from? thanks, azdel From Celierra at gmail.com Sun Sep 7 22:52:45 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sun Sep 7 22:52:47 2008 Subject: [sldev] cmake compile issues In-Reply-To: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> References: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> Message-ID: On Mon, Sep 8, 2008 at 1:37 AM, azdel slade wrote: > Hi, >> Also, why is this parentheses: > > (If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to > "linden\libraries\i686-win32\lib\release" and to > "linden\libraries\i686-win32\lib\debug") > > on the page for cmake instructions? curious. > > Also, I think that the ares and openjpeg instructions should probably > be moved into the own section, like "compiling older sources". Since > the parentheses are easy to miss. > Are you looking at the wrong page? You seem to be talking about http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) , but you should be looking at http://wiki.secondlife.com/wiki/CMake . The only thing you should be doing from the MSVS2005 page is the thing involving Fmod. From secondloop at gmail.com Sun Sep 7 23:26:41 2008 From: secondloop at gmail.com (azdel slade) Date: Sun Sep 7 23:26:45 2008 Subject: [sldev] cmake compile issues In-Reply-To: References: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> Message-ID: <1e0ce1090809072326o281f10e8icae1c58e062b0b7e@mail.gmail.com> Doh! You're so right, sorry! But I still have the problem that llkdu.dll is missing, but SL appears to run. But then, it complains that Openjpeg.dll is not found, and exits. On Sun, Sep 7, 2008 at 10:52 PM, Celierra Darling wrote: > On Mon, Sep 8, 2008 at 1:37 AM, azdel slade wrote: >> Hi, >>> Also, why is this parentheses: >> >> (If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to >> "linden\libraries\i686-win32\lib\release" and to >> "linden\libraries\i686-win32\lib\debug") >> >> on the page for cmake instructions? curious. >> >> Also, I think that the ares and openjpeg instructions should probably >> be moved into the own section, like "compiling older sources". Since >> the parentheses are easy to miss. >> > > Are you looking at the wrong page? You seem to be talking about > http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) , but > you should be looking at http://wiki.secondlife.com/wiki/CMake . The > only thing you should be doing from the MSVS2005 page is the thing > involving Fmod. > From Celierra at gmail.com Sun Sep 7 23:26:49 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sun Sep 7 23:26:52 2008 Subject: [sldev] Better build instructions In-Reply-To: References: <1ds4ds5dY4du4s0ee04ds5u.alissa_sabre@yahoo.co.jp> Message-ID: Bumping this thread back up... It looks like Sardonyx Linden started to convert https://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) to post-cmake instructions, but people haven't realized what had happened (someone even added "instructions for after 1.21 are not available" a month later). So that page was a rather incoherent jumble of both. This seems to have been confusing a lot of people. I've temporarily undone Sardonyx's changes, sending people with 1.21+ sources to the cmake page. But there needs to be some more lasting solution. I don't think we ever concluded how exactly to structure these pages - was there a decision? Cel From secondloop at gmail.com Sun Sep 7 23:37:04 2008 From: secondloop at gmail.com (azdel slade) Date: Sun Sep 7 23:37:07 2008 Subject: [sldev] cmake compile issues In-Reply-To: <1e0ce1090809072326o281f10e8icae1c58e062b0b7e@mail.gmail.com> References: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> <1e0ce1090809072326o281f10e8icae1c58e062b0b7e@mail.gmail.com> Message-ID: <1e0ce1090809072337t15ce624ch490c6af2b0a95a9f@mail.gmail.com> And the missing dll errors continue. I did download the libs and copy them into the right place. But I tried copying openjpeg.dll into newview, and then it complained about xul, then js3250, then nspr4, and now MSVCR71d.dll, which I can't copy over because its not anywhere to be found on my machine... hmm... On Sun, Sep 7, 2008 at 11:26 PM, azdel slade wrote: > Doh! You're so right, sorry! > > But I still have the problem that llkdu.dll is missing, but SL appears > to run. But then, it complains that Openjpeg.dll is not found, and > exits. > > On Sun, Sep 7, 2008 at 10:52 PM, Celierra Darling wrote: >> On Mon, Sep 8, 2008 at 1:37 AM, azdel slade wrote: >>> Hi, >>>> Also, why is this parentheses: >>> >>> (If using cmake, copy "fmodapi375win\api\lib\fmodvc.lib" to >>> "linden\libraries\i686-win32\lib\release" and to >>> "linden\libraries\i686-win32\lib\debug") >>> >>> on the page for cmake instructions? curious. >>> >>> Also, I think that the ares and openjpeg instructions should probably >>> be moved into the own section, like "compiling older sources". Since >>> the parentheses are easy to miss. >>> >> >> Are you looking at the wrong page? You seem to be talking about >> http://wiki.secondlife.com/wiki/Compiling_the_viewer_(MSVS2005) , but >> you should be looking at http://wiki.secondlife.com/wiki/CMake . The >> only thing you should be doing from the MSVS2005 page is the thing >> involving Fmod. >> > From Celierra at gmail.com Sun Sep 7 23:46:27 2008 From: Celierra at gmail.com (Celierra Darling) Date: Sun Sep 7 23:46:29 2008 Subject: [sldev] Help compiling In-Reply-To: <20080908035440.21A0141AFB6@stupor.lindenlab.com> References: <20080908035440.21A0141AFB6@stupor.lindenlab.com> Message-ID: Sorry, the state of that page seems to have gotten caught between post-cmake and pre-cmake. The develop.py bit is just for 1.21 and later. IIRC, later Windows SDKs seemed to work okay; I guess it's backwards-compatible and they just list the latest supported version in the title of the SDK (but I'm just guessing). dinput8.lib seems to come from the DirectX SDK. Be sure that the paths are set correctly to the ( http://wiki.secondlife.com/wiki/Microsoft_Visual_Studio#Setup_the_project_globals ). Cel From secondloop at gmail.com Mon Sep 8 00:24:06 2008 From: secondloop at gmail.com (azdel slade) Date: Mon Sep 8 00:24:08 2008 Subject: [sldev] cmake compile issues In-Reply-To: References: <1e0ce1090809072237r4718217chd82f148077013194@mail.gmail.com> <1e0ce1090809072326o281f10e8icae1c58e062b0b7e@mail.gmail.com> <1e0ce1090809072337t15ce624ch490c6af2b0a95a9f@mail.gmail.com> Message-ID: <1e0ce1090809080024n6f450b3l833a4b5b8d862691@mail.gmail.com> OMG, i deleted the llkdu.dll rules from the copy-win-libs project and now it works! thank you! my first build that actually ran. super exciting. azdel On Sun, Sep 7, 2008 at 11:58 PM, Celierra Darling wrote: > MSVCR71d.dll seems to be connected with VS 2003? That seems quite > wrong. Can you check to make sure that your project is in > indra\build-vc80, and not ...build-vc71 ? > > Also, most of those libraries should have been copied when building > the copy_win_libs project. Try building that project again? > > llkdu.dll is weird; to me, SL doesn't seem to need it, so I just > delete the "llkdu.dll.rule" files CMake Rules folder of the > copy_win_libs project. > From AndromedaQuonset at comcast.net Mon Sep 8 02:54:17 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Mon Sep 8 02:54:05 2008 Subject: [sldev] Help compiling Message-ID: <20080908095403.E645541B167@stupor.lindenlab.com> Thank you Vector, and Celierra! I am still trying to install the SDK for Windows Server 2008. Perhaps I'll have more questions in a day or two. The hour is getting late here :) Andro At 02:41 AM 9/8/2008, you wrote: >I hope you've solved your problem. > >If not, maybe this will help. I'm not very experiences, so this may sound >silly. But I too created an unholy mess in my first few days trying to get >it to compile. > >It's very complicated, but the information is there on the wikis, you just >have to sort through what's not relevant, and that takes some trial and >error. What I succeeded at was the 1.20 build. > >Notice what other's have said about the python script being only for 1.21 >CMake installs. You can ignore for a MSVS2005. > >Do the build of the additional libraries you need (fmod, openjpeg, etc.) >into the separate library tree. > >Then zip that up. > >Then download all three of the zip files from the source page (check the >text on them, because sometimes the pointers on the page get messed up and >it will cause you to download mis-matched packages despite the fact you >clicked on the right link. If the links aren't there for matched package >sets, go and update the wiki to simply fix the names. I hope that made >sense.) > >Get Artwork, source, and libs from the source downloads page. > >Then unzip to a fresh directory in this order: > >1. Your created tree of library add-ons >2. Linden's artwork >3. Linden's source >4. Linden's libs. > >Those last three really don't matter what order they're in, it matters that >they come after 1, because you may find some files get replaced. These will >cause run-time errors if you don't use the ones from linden's packages. > >Once you do that and follow the converting project files wiki page you >mention, you CAN compile Release 1.20 on MSVS2005 Express. > >Good luck! > >Vector Hastings > >-----Original Message----- >From: sldev-bounces@lists.secondlife.com >[mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Andromeda >Quonset >Sent: Sunday, September 07, 2008 8:55 PM >To: sldev@lists.secondlife.com >Subject: [sldev] Help compiling > > >Greetings! > >I do not have VS2003. I have VS2002, VS2005, VS2008 Express. The >one I am _comfortable_ with is VS6.0. > >I have been attempting to compile the client. What I seem to have >accomplished is created a mess. > >I decided to use VS2005 as the best choice among the compilers I >have. The client version I chose was 1.19.1 >I am running under Windows XP SP2, 32-bit. >I have attempted to download all the myriad of files. I found I >needed to upgrade VS2005 to SP1. So, that's done. > >At one point, under "Configuring for VS2005" >http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29, >it says "To configure, go into linden\indra and run develop.py -G >VC80. This will create a build directory named build-VC80. " > >I can safely say that there is no "develop.py" in "linden\indra" or >anywhere else in the system. Nor can I find out where I might >download it from. With that lacking, I've gone to >http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 >where I have done the conversion manually. > >I have gotten from over 4,000 errors, to where I only have a few >errors. Much of that was from the XML code that was pre-pended >inside of the openGL headers. At the moment, I am stuck at "Link : >fatal error LNK1104: cannot open file 'dinput8.lib' > >There are other errors that appear earlier, over 250 of them, but >since linking gets invoked, I don't know if they matter or not. > >One other thing: the wiki says I need to obtain and install >something called "Microsoft Windows Server 2003 R2 Platform >SDK". This is no longer available. When you jump through all the >hoops to download it at the Microsoft site, what happens is you end >up on a download site for "Windows SDK for Windows Server 2008 and >.NET Framework 3.5". I have gone ahead and downloaded this, however, >since it isn't the version specified, I have not installed it. I >don't understand, anyway, why I would need this. I'm not running a >Windows "server" OS of any flavor here. > >_______________________________________________ >Policies and (un)subscribe information available here: >http://wiki.secondlife.com/wiki/SLDev >Please read the policies before posting to keep unmoderated posting >privileges From me at signpostmarv.name Mon Sep 8 04:28:30 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Sep 8 04:28:31 2008 Subject: [sldev] checking how the viewer gets Event info Message-ID: <48C50C5E.8060408@signpostmarv.name> Can someone point me in the direction of the code the viewer uses to get the info to display SL Events ? I've tried searching through the viewer source (thanks McCabe!), but since I'm not entirely certain what it is I'm looking for (and mostly what I'm looking at :-s ), I'm at a loss. ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080908/0a7f3d33/smime.bin From sllists at boroon.dasgupta.ch Mon Sep 8 05:02:26 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Sep 8 05:02:31 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') Message-ID: <48C51452.4000305@boroon.dasgupta.ch> Hi all Because the existing thread (https://lists.secondlife.com/pipermail/sldev/2008-July/thread.html#11069) is some time ago, I create a new one instead of bumping. I re-re-tried to build svn trunk, closely following the instructions at https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake (only difference should be that I chose trunk/linden instead of just trunk as checkout destination directory). Just as back in July, I still get the following errors with the current revision (1153): > [...] > Linking CXX static library libllui.a > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > [ 44%] Built target llui > make[2]: Entering directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > Scanning dependencies of target linux-crash-logger > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make[2]: Entering directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > [ 44%] Building CXX object > linux_crash_logger/CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o > [ 44%] Building CXX object > linux_crash_logger/CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o > Linking CXX executable linux-crash-logger > /home//slsrc/svn/trunk/*linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Realloc'* > /home//slsrc/svn/trunk/*linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Alloc'* > /home//slsrc/svn/trunk/*linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Free'* > collect2: ld returned 1 exit status > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make[1]: *** > [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] Error 2 > make[1]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make: *** [all] Error 2 > make: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > Error: the command 'make' exited with status 2 Can anyone give me a hint on what might be going wrong here? I'm using a gentoo linux (i686) system with * gcc 4.1.2 * python 2.5.2 * cmake 2.4.8 All help appreciated! Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/0e4ae99e/attachment-0001.htm From chaosstar at gmail.com Mon Sep 8 05:32:47 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Sep 8 05:32:50 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <48C51452.4000305@boroon.dasgupta.ch> References: <48C51452.4000305@boroon.dasgupta.ch> Message-ID: <9bb32d430809080532l51a8b5f5pe203ee3dcba9e07a@mail.gmail.com> I wonder. It sounds like the freetype development libraries are not installed. are you sure libfreetype6-dev (or a simiiar package in non-ubuntu/debian based distros) is installed on your system? Also, has the 'develop.py configure' step grabbed all remote libraries without errors? On Mon, Sep 8, 2008 at 14:02, Boroondas Gupte wrote: > Hi all > > Because the existing thread > (https://lists.secondlife.com/pipermail/sldev/2008-July/thread.html#11069) > is some time ago, I create a new one instead of bumping. > > I re-re-tried to build svn trunk, closely following the instructions at > https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake (only > difference should be that I chose trunk/linden instead of just trunk as > checkout destination directory). Just as back in July, I still get the > following errors with the current revision (1153): > > [...] > Linking CXX static library libllui.a > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > [ 44%] Built target llui > make[2]: Entering directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > Scanning dependencies of target linux-crash-logger > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make[2]: Entering directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > [ 44%] Building CXX object > linux_crash_logger/CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o > [ 44%] Building CXX object > linux_crash_logger/CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o > Linking CXX executable linux-crash-logger > /home//slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Realloc' > /home//slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Alloc' > /home//slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: > undefined reference to `FT_Free' > collect2: ld returned 1 exit status > make[2]: *** [linux_crash_logger/linux-crash-logger] Error 1 > make[2]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make[1]: *** [linux_crash_logger/CMakeFiles/linux-crash-logger.dir/all] > Error 2 > make[1]: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > make: *** [all] Error 2 > make: Leaving directory > `/home//slsrc/svn/trunk/linden/indra/viewer-linux-i686' > Error: the command 'make' exited with status 2 > > Can anyone give me a hint on what might be going wrong here? > I'm using a gentoo linux (i686) system with > > gcc 4.1.2 > python 2.5.2 > cmake 2.4.8 > > All help appreciated! > > Boroondas > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From chaosstar at gmail.com Mon Sep 8 05:28:18 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Sep 8 05:35:27 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: <48C50C5E.8060408@signpostmarv.name> References: <48C50C5E.8060408@signpostmarv.name> Message-ID: <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> What kind of events are you referring to? if you mean things like payments, notifications et al, I suggest peeking at llViewerMessage.cpp It's a monolithic chunk of the whole message handling. Messages in this contect being special info the sim sends to the client, and vice versa. Think of it as commands to do X. if you create a prim, the viewer sends a formatted message with your key, the command, prim specifics etc. to the sim, and it creates it. if somebody IMs you, the sim sends a message via the message system to your client, which then checks if it is already in a session with the person or not, and so on. It's the best place to start. On Mon, Sep 8, 2008 at 13:28, SignpostMarv Martin wrote: > Can someone point me in the direction of the code the viewer uses to get the > info to display SL Events ? > > I've tried searching through the viewer source (thanks McCabe!), but since > I'm not entirely certain what it is I'm looking for (and mostly what I'm > looking at :-s ), I'm at a loss. > > > ~ Marv. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From sllists at boroon.dasgupta.ch Mon Sep 8 06:00:40 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Sep 8 06:00:46 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <9bb32d430809080532l51a8b5f5pe203ee3dcba9e07a@mail.gmail.com> References: <48C51452.4000305@boroon.dasgupta.ch> <9bb32d430809080532l51a8b5f5pe203ee3dcba9e07a@mail.gmail.com> Message-ID: <48C521F8.5020002@boroon.dasgupta.ch> Ambrosia schrieb: > I wonder. It sounds like the freetype development libraries are not installed. > > are you sure libfreetype6-dev (or a simiiar package in > non-ubuntu/debian based distros) is installed on your system? Also, > has the 'develop.py configure' step grabbed all remote libraries > without errors? Hi Ambrosia, thanks for the answer. I've got media-libs/freetype-2.3.7 installed (about half my system seems to depend on it). Do I have to copy any of the files provided by it (like /usr/lib/libfreetype.so.6.3.18, /usr/lib/libfreetype.a or /usr/lib/libfreetype.la) somewhere into the SL source tree? 'develop.py configure' seems to be happy. When re-run it outputs: >> $> *./develop.py configure* >> Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO >> -G \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE >> -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" >> \'/home//slsrc/svn/trunk/linden/indra\'' in 'viewer-linux-i686' >> -- Building with FMOD audio support >> -- Building with FMOD audio support >> -- Version of viewer is 1.21.0.0 >> -- Configuring done >> -- Generating done >> -- Build files have been written to: >> /home//slsrc/svn/trunk/linden/indra/viewer-linux-i686 >> $> *echo $?* >> 0 Boroondas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/9680b1e0/attachment.htm From me at signpostmarv.name Mon Sep 8 06:08:08 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Mon Sep 8 06:08:09 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> Message-ID: <48C523B8.3070205@signpostmarv.name> Ambrosia wrote: > What kind of events are you referring to? > In-world events, as in the things people host and spamalot :-P -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080908/64025b55/smime.bin From chaosstar at gmail.com Mon Sep 8 06:33:12 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Sep 8 06:33:16 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <48C521F8.5020002@boroon.dasgupta.ch> References: <48C51452.4000305@boroon.dasgupta.ch> <9bb32d430809080532l51a8b5f5pe203ee3dcba9e07a@mail.gmail.com> <48C521F8.5020002@boroon.dasgupta.ch> Message-ID: <9bb32d430809080633r4076dcc7o8caa94a3f3348547@mail.gmail.com> You listed the .so, .a and .la files. Those are the finished, compiled freetype libraries..but not the development package :> Basically, in most distros, packages ending with -dev contain the source code for the appropriate item. in this case, the freetype library source. Since you are using Gentoo tho, the source should be on your system in the first place. I wonder. It's been a while since I used gentoo, but search Portage for a specific -dev package for that lib, and/or check if the source is still on your system. On Mon, Sep 8, 2008 at 15:00, Boroondas Gupte wrote: > Ambrosia schrieb: > > I wonder. It sounds like the freetype development libraries are not > installed. > > are you sure libfreetype6-dev (or a simiiar package in > non-ubuntu/debian based distros) is installed on your system? Also, > has the 'develop.py configure' step grabbed all remote libraries > without errors? > > Hi Ambrosia, > thanks for the answer. > > I've got media-libs/freetype-2.3.7 installed (about half my system seems to > depend on it). Do I have to copy any of the files provided by it (like > /usr/lib/libfreetype.so.6.3.18, /usr/lib/libfreetype.a or > /usr/lib/libfreetype.la) somewhere into the SL source tree? > > 'develop.py configure' seems to be happy. When re-run it outputs: > > $> ./develop.py configure > Running 'CXX=\'g++\' cmake -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -G > \'Unix Makefiles\' -DSERVER:BOOL=FALSE -DVIEWER:BOOL=TRUE > -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" > \'/home//slsrc/svn/trunk/linden/indra\'' in 'viewer-linux-i686' > -- Building with FMOD audio support > -- Building with FMOD audio support > -- Version of viewer is 1.21.0.0 > -- Configuring done > -- Generating done > -- Build files have been written to: > /home//slsrc/svn/trunk/linden/indra/viewer-linux-i686 > $> echo $? > 0 > > Boroondas > From chaosstar at gmail.com Mon Sep 8 06:41:00 2008 From: chaosstar at gmail.com (Ambrosia) Date: Mon Sep 8 06:41:03 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: <48C523B8.3070205@signpostmarv.name> References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> Message-ID: <9bb32d430809080641r459e7017h1ffb4d28e5e3cc82@mail.gmail.com> Heh, I see :D Sorry, didn't think of literal SL events. But, my pointer kind of still stands. check llviewermessage.cpp for world map messages/search messages, depending on how the event info is retrieved. They might be one of the message types not in that file tho, but I can't check right now. I'll drop another post in about one and a half hours, when I got home and digged into the source some :> Another way to start your hunt is to check the event search floater xml for the function the search button runs, and the combobox name for choosing event types.Grep that, and you should find the event search methods in the source. There, look for the method that tosses the sim the search message, and see if you can find the callback/observer methods that catch the sim's reply. If the above is a little too confusing..as I said, I'll check when I get home and post findings :> On Mon, Sep 8, 2008 at 15:08, SignpostMarv Martin wrote: > Ambrosia wrote: >> >> What kind of events are you referring to? >> > > In-world events, as in the things people host and spamalot :-P > > From robin.cornelius at gmail.com Mon Sep 8 06:59:20 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 8 06:59:25 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: <48C523B8.3070205@signpostmarv.name> References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> Message-ID: On Mon, Sep 8, 2008 at 2:08 PM, SignpostMarv Martin wrote: > Ambrosia wrote: >> >> What kind of events are you referring to? >> > > In-world events, as in the things people host and spamalot :-P > > All the search code is pretty much self contained within newview/llpaneldirevents.cpp llpaneldirevents::performQuery() does the query The events are received into llpaneldirbrowser.cpp LLPanelDirBrowser::processDir****Reply() for the various events/people etc searches LLPanelDirEvents has LLPanelDirBrowser as a parent class as do each of the other search panels. Robin From bill.hoffman at kitware.com Mon Sep 8 07:12:37 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Mon Sep 8 07:12:53 2008 Subject: [sldev] CMake 2.6.2 RC 3 Message-ID: <48C532D5.3050300@kitware.com> Hi folks, I have a RC for CMake 2.6.2. One of the driving forces behind getting out a new 2.6 release was to build second life (as there are some issues with 2.6.1). This release should address all of the remaining SL issues. Please give it a try and let me know if you find any new problems. I have binaries for CMake 2.6.2 RC 3 here: http://www.cmake.org/files/v2.6/?C=M;O=D Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman@kitware.com http://www.kitware.com 518-371-3971 (phone and fax) From chess at us.ibm.com Mon Sep 8 07:36:37 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Sep 8 07:36:44 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080907032250.1AD46113A0B@stupor.lindenlab.com> Message-ID: > From: "Edward Artaud" > Clearly there's some change in roadmap implied by the introduction of > SLim that these OGP plans aren't taking into consideration. I don't think so. From talking to at least some of the relevant Lindens, the plan is still to get SL IM off of the simulators and into the Agent Domain. And we'll still have exactly the same questions to ask in OGP about what information has to flow between grids in order for inter-grid IM to work. How LL is implementing this particular one-grid non-viewer-client gateway is an interesting datapoint (i.e. it might tell us something about a use-case or a new requirement that we didn't already know), but it doesn't change anything major about the OGP work as far as I can tell... Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/1af251f7/attachment.htm From chess at us.ibm.com Mon Sep 8 07:36:37 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Sep 8 07:36:45 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080906170011.F0D731139AD@stupor.lindenlab.com> Message-ID: > From: "Teravus Ovares" > A long long time ago, I created the following diagram of how XMPP could work.. > http://opensimulator.org/images/1/1c/Proposed_IM_Flow.jpg > http://opensimulator.org/wiki/Proposed_IM_Flow Good stuff! I have linked to that from the See Also on the Wiki page (that number again: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP ). Does the diagram cover group IM as well as person-to-person? I didn't notice it, but I don't know the XMPP concepts as well as I should. > To sum it up.. an XMPP server with each region serving as an XMPP over > BOSH gateway.. with a few tricks to support the legacy protocol and 3D > space management using the 'resource'. Would it be hard to draw the picture using the agent domain instead of the region domain? That's what we're currently assuming, I think, in the AWG: get the burden off of the RD server. > There are little nuances that make direct transition to XMPP more > challenging then just switching. Glad to hear you say this! :) I've been trying to explain this to people who say "it's simple! just switch to [favorite existing IM system here] and you're done!". > Best Regards > Teravus Tx, Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/0651b9c5/attachment.htm From chess at us.ibm.com Mon Sep 8 08:00:48 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Sep 8 08:00:53 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080908010010.0E34E113ABF@stupor.lindenlab.com> Message-ID: From: "Christian Scholz / Tao Takashi (SL)" > I also wonder if the group situation will stay that way on the long > run with OGP. Right now with only 25 groups you probably need to stay > in the big groups to stay connected. If you wouldn't have that > requirment and the whole world is more decentralized anyway I wonder > if those groups would look different. Additionally if you are more > free to join and leave without any hassle (like you might do with IRC > channels). Right now with that limit you always have to think plus I > think some groups have member restrictions because of the lag (IIRC). Just as a datapoint, I as a private Resident would be quite unhappy with a change to the group system such that I had to explicitly "join" the Group IM channel for all my chat groups once per logon (say) in order to see the Group IM. > But of course we also need to find a solution to support the existing > group model with those huge groups. > BTW, what are the actual numbers for the bigger ones? Some random data points: Money Island VIP (raffle) 9984, Fashion Consolidated (open) 9009, The Wild Coast (pay to join) 5640, Eightbar (invitation only) 4600, Lucky Money Chair (open) 4529, Scripters of Second Life (geeks lol) 1974. > So pluggability might be key and the question is how we can support > both: Some not so secure environment where you maybe can simply join > some non-SL IM system like Jabber or IRC without further identity > check Presumably that can be done by just embedding an IRC or Jabber client into some viewer. Or just running it in a different process on the same machine. :) No OGP implications, I don't think. I don't see a strong use-case for it, myself; why should an SL viewer contain a way for me to chat with random people whos RL and SL identities I don't know? We already have programs for that. > and a more secure one like the one we have now where you can be > sure that "Tao Takashi@syntronik.de" (imagine this would be my full > qualified name in OGP) really is me. Additionally there might be a mix > of both but where you can distinguish not verified agents as such. The secure one seems like the primary use-case to me; the mixed case would be a nice addition, where people can come into the secure system without being verified, as long as they're clearly marked as such. > Also I think the IM service should be kept outside the AD but can ask > the AD for verification of somebody. That's roughly what the current proposal on the Wiki says: use the AD for identity, but don't flow the actual message traffic through it. Your comments there would be most welcome, although I know you hate the poor Wiki. :) > So that means you have to trust the IM service to do the > authentication and of course the ADs in question to answer it > correctly. The details "just" need to be worked out ;-) My preference would be to do this by having the IM service under the control of the AD; avoids having another entity to have to trust. > Another thing I am thinking about is how we can also use service > discovery (e.g. by using XRDS-Simple or the successor protocol which > is worked on right now) for each person to check which IM service it > prefers to be contacted under. Would seem at least as logical to me for the AD to know that (since the AD knows other stuff about me anyway). But whatever works. :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/c054e527/attachment.htm From sllists at boroon.dasgupta.ch Mon Sep 8 08:12:11 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Sep 8 08:12:15 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <9bb32d430809080633r4076dcc7o8caa94a3f3348547@mail.gmail.com> References: <48C51452.4000305@boroon.dasgupta.ch> <9bb32d430809080532l51a8b5f5pe203ee3dcba9e07a@mail.gmail.com> <48C521F8.5020002@boroon.dasgupta.ch> <9bb32d430809080633r4076dcc7o8caa94a3f3348547@mail.gmail.com> Message-ID: <48C540CB.1080106@boroon.dasgupta.ch> Ambrosia schrieb: > You listed the .so, .a and .la files. Those are the finished, compiled > freetype libraries..but not the development package :> > > Basically, in most distros, packages ending with -dev contain the > source code for the appropriate item. in this case, the freetype > library source. Since you are using Gentoo tho, the source should be > on your system in the first place. I wonder. It's been a while since I > used gentoo, but search Portage for a specific -dev package for that > lib, and/or check if the source is still on your system. As far as I know, gentoo doesn't have any *-dev packages. I can get the source by unpacking /usr/portage/distfiles/freetype-2.3.7.tar.bz2, but I can't imagine why SL would need it, or where I'd have to place it to be found. Here's all the files media-libs/freetype-2.3.7 comes with: >> $> equery files freetype >> [ Searching for packages matching freetype... ] >> * Contents of media-libs/freetype-2.3.7: >> /usr >> /usr/bin >> /usr/bin/freetype-config >> /usr/include >> /usr/include/freetype2 >> /usr/include/freetype2/freetype >> /usr/include/freetype2/freetype/config >> /usr/include/freetype2/freetype/config/ftconfig.h >> /usr/include/freetype2/freetype/config/ftheader.h >> /usr/include/freetype2/freetype/config/ftmodule.h >> /usr/include/freetype2/freetype/config/ftoption.h >> /usr/include/freetype2/freetype/config/ftstdlib.h >> /usr/include/freetype2/freetype/freetype.h >> /usr/include/freetype2/freetype/ftbbox.h >> /usr/include/freetype2/freetype/ftbdf.h >> /usr/include/freetype2/freetype/ftbitmap.h >> /usr/include/freetype2/freetype/ftcache.h >> /usr/include/freetype2/freetype/ftchapters.h >> /usr/include/freetype2/freetype/ftcid.h >> /usr/include/freetype2/freetype/fterrdef.h >> /usr/include/freetype2/freetype/fterrors.h >> /usr/include/freetype2/freetype/ftgasp.h >> /usr/include/freetype2/freetype/ftglyph.h >> /usr/include/freetype2/freetype/ftgxval.h >> /usr/include/freetype2/freetype/ftgzip.h >> /usr/include/freetype2/freetype/ftimage.h >> /usr/include/freetype2/freetype/ftincrem.h >> /usr/include/freetype2/freetype/ftlcdfil.h >> /usr/include/freetype2/freetype/ftlist.h >> /usr/include/freetype2/freetype/ftlzw.h >> /usr/include/freetype2/freetype/ftmac.h >> /usr/include/freetype2/freetype/ftmm.h >> /usr/include/freetype2/freetype/ftmodapi.h >> /usr/include/freetype2/freetype/ftmoderr.h >> /usr/include/freetype2/freetype/ftotval.h >> /usr/include/freetype2/freetype/ftoutln.h >> /usr/include/freetype2/freetype/ftpfr.h >> /usr/include/freetype2/freetype/ftrender.h >> /usr/include/freetype2/freetype/ftsizes.h >> /usr/include/freetype2/freetype/ftsnames.h >> /usr/include/freetype2/freetype/ftstroke.h >> /usr/include/freetype2/freetype/ftsynth.h >> /usr/include/freetype2/freetype/ftsystem.h >> /usr/include/freetype2/freetype/fttrigon.h >> /usr/include/freetype2/freetype/fttypes.h >> /usr/include/freetype2/freetype/ftwinfnt.h >> /usr/include/freetype2/freetype/ftxf86.h >> /usr/include/freetype2/freetype/t1tables.h >> /usr/include/freetype2/freetype/ttnameid.h >> /usr/include/freetype2/freetype/tttables.h >> /usr/include/freetype2/freetype/tttags.h >> /usr/include/freetype2/freetype/ttunpat.h >> /usr/include/ft2build.h >> /usr/lib >> /usr/lib/libfreetype.a >> /usr/lib/libfreetype.la >> /usr/lib/libfreetype.so -> libfreetype.so.6.3.18 >> /usr/lib/libfreetype.so.6 -> libfreetype.so.6.3.18 >> /usr/lib/libfreetype.so.6.3.18 >> /usr/lib/pkgconfig >> /usr/lib/pkgconfig/freetype2.pc >> /usr/share >> /usr/share/aclocal >> /usr/share/aclocal/freetype2.m4 >> /usr/share/doc >> /usr/share/doc/freetype-2.3.7 >> /usr/share/doc/freetype-2.3.7/CHANGES.bz2 >> /usr/share/doc/freetype-2.3.7/CUSTOMIZE.bz2 >> /usr/share/doc/freetype-2.3.7/ChangeLog.bz2 >> /usr/share/doc/freetype-2.3.7/DEBUG.bz2 >> /usr/share/doc/freetype-2.3.7/PATENTS.bz2 >> /usr/share/doc/freetype-2.3.7/README.bz2 >> /usr/share/doc/freetype-2.3.7/TODO.bz2 >> /usr/share/doc/freetype-2.3.7/formats.txt.bz2 >> /usr/share/doc/freetype-2.3.7/raster.txt.bz2 I noticed that in the pre-cmake build process, the header directory /usr/include/freetype2/freetype/ was copied into the tree, but nowadays the destination is already populated by './develop.py configure' with files from freetype-2.1.5. I just tried replacing them with the ones from /usr/include/freetype2/freetype/, but the linking errors persisted. The relevant declarations seem to be in ./linden/libraries/include/freetype/internal/ftmemory.h, which isn't present under /usr/include anyway. Boroondas From chess at us.ibm.com Mon Sep 8 08:12:54 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Sep 8 08:12:57 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080908010010.0E34E113ABF@stupor.lindenlab.com> Message-ID: > From: "Edward Artaud" > Having built these types of group chat systems in the past, at a > certain point, they tend to move to a pull model of polling a chat > history rather than the push message propagation model, so that the > client can basically ask the server to deliver to it the new chat > events posted since the last poll time. After all, there's a reason > why there's a limit to the number of agents you can have in a single > region, the problem with groups is that they often have an order of > magnitude more members. I don't really understand this scaling argument. In my experience, neither "push everything everywhere" nor "constantly ask if there's anything new" scales; what scales is actual pub/sub. In the case of group IM, messages get pushed by some server (or some cluster of entities acting as a logical server) to all and only those places where someone cares. There's some overhead in keeping track of where there are places that someone cares, but in most use-cases I've seen it's the approach that scales the best. Dale Innis DaleInnisEmail@gmail.com or if I were to sign this as the person who actually has experience in this area :) Dave Chess chess@us.ibm.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/ec26115a/attachment-0001.htm From chess at us.ibm.com Mon Sep 8 08:12:54 2008 From: chess at us.ibm.com (David M Chess) Date: Mon Sep 8 08:14:05 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080908010010.0E34E113ABF@stupor.lindenlab.com> Message-ID: > From: Lawson English > My conception for the current group IM as it could be done in OGP, is > simply to make the Agent Domain responsible for forwarding group > messages to individual avies. The IM server tracks membership AND the > associated Agent Domain and sends the Agent domain a message for each > group with recipients attached (or the AD could request such a list). > The AD is responsible for determining if a given recipient is online or > not, and forwarding the message to the client or to email or just eating > it. Responses to the group IM server are sent directly to the server or > they could be collected and forwarded in some way. Would you be willing to work on filling in the details of this and writing down what messages it would require in OGP? And comparing it to the strawman currently on the Wiki page? (Which is similar but different.) I'm worried by all those wasted messages from the IM server to an AD none of whose group members is currently logged on, for instance, but it's hard to do a detailed analysis without a detailed design... > In any case, arbitrarily deciding to forgo the current SL group IM > design is not really an option, as far as I am concerned. The SL > community is set up aground the current chat behavior (missing messages > and errors aside), and to suddenly change that would be more than a > little disruptive. No need to limit ourselves to just the SL model, but > to just chuck it out is a big no-no. Definite agreement. There are really two discussions here: how does OGP support IM between grids, and how do we fix IM within SL (and the other existing grids). The questions are related, but different... Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/1d0d5a5d/attachment.htm From lenglish5 at cox.net Mon Sep 8 08:18:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 8 08:18:42 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> Message-ID: <48C54250.9010709@cox.net> Robin Cornelius wrote: > On Mon, Sep 8, 2008 at 2:08 PM, SignpostMarv Martin > wrote: > >> Ambrosia wrote: >> >>> What kind of events are you referring to? >>> >>> >> In-world events, as in the things people host and spamalot :-P >> >> >> > > All the search code is pretty much self contained within > newview/llpaneldirevents.cpp > > llpaneldirevents::performQuery() does the query > > The events are received into llpaneldirbrowser.cpp > > LLPanelDirBrowser::processDir****Reply() > > for the various events/people etc searches > > LLPanelDirEvents has LLPanelDirBrowser as a parent class as do each of > the other search panels. > > That is something I gotta start looking at for pyogp. Working on a tentative design for a GUI module for it ATM. One thing I think we want (I'm sure *I* want) is to keep the GUI separate from the functionality. One of the GPL viewer's biggest stumbling blocks for modifying the GUI is how intimately connected the GUI is with the specific packets and functionality it deals with. There's no abstraction between the primitive tk-level (think the GUI is a TK port) widgets and the SL-specific widgets. No folder class save inventory folders, for example. I'm guessing that there are no chat panels that could accept a Jabber or IRC plugin input, eitehr, without a LOT of extra work. 3D scenegraph display aside, I think pyogp would be ideal for helping design the next generation GUI for the SL viewer, in case anyone wants to throw in a few suggestions... Lawson From robin.cornelius at gmail.com Mon Sep 8 08:19:17 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 8 08:19:21 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <48C51452.4000305@boroon.dasgupta.ch> References: <48C51452.4000305@boroon.dasgupta.ch> Message-ID: On Mon, Sep 8, 2008 at 1:02 PM, Boroondas Gupte wrote: > Hi all > > Because the existing thread > (https://lists.secondlife.com/pipermail/sldev/2008-July/thread.html#11069) > is some time ago, I create a new one instead of bumping. > > I re-re-tried to build svn trunk, closely following the instructions at > https://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/cmake (only > difference should be that I chose trunk/linden instead of just trunk as > checkout destination directory). Just as back in July, I still get the > following errors with the current revision (1153): > Can you re run the build with ./develop.py build VERBOSE=1 and post the actual ld line that is generating the error and also can I have a look at your indra/CMakeCache.txt file. It will be the last thing before all the errors spit out. Robin From robin.cornelius at gmail.com Mon Sep 8 08:30:28 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 8 08:30:32 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: <48C54250.9010709@cox.net> References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> <48C54250.9010709@cox.net> Message-ID: On Mon, Sep 8, 2008 at 4:18 PM, Lawson English wrote: > That is something I gotta start looking at for pyogp. Working on a tentative > design for a GUI module for it ATM. > > One thing I think we want (I'm sure *I* want) is to keep the GUI separate > from the functionality. One of the GPL viewer's biggest stumbling blocks for > modifying the GUI is how intimately connected the GUI is with the specific > packets and functionality it deals with. There's no abstraction between the > primitive tk-level (think the GUI is a TK port) widgets and the SL-specific > widgets. No folder class save inventory folders, for example. I'm guessing > that there are no chat panels that could accept a Jabber or IRC plugin > input, eitehr, without a LOT of extra work. > yea for sure. In the current implementation there are packet handling routines scattered through out the code, such as in the specific floaters for event searches the search packets are generated and sent from there. At least the packet receive code has *some* abstraction, it at least comes up a common path when it gets switched to the various functions that may deal with it but even in this case it looks for a static instance of a LLPanelDirEvents and feeds the call back directly in there. This is where creating a GUI on top of libomv (libsecondlife) was a joy. Keeping the message API out of the higher level code makes things more readable and obvious and hopefully makes bug hunting a little easier. I suppose in theory this could be done with the existing viewer almost a message group at a time so its a gradual change and not a "refactor". Robin From sllists at boroon.dasgupta.ch Mon Sep 8 08:42:50 2008 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Mon Sep 8 08:42:56 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: References: <48C51452.4000305@boroon.dasgupta.ch> Message-ID: <48C547FA.1050109@boroon.dasgupta.ch> Hi Robin, thanks for answering. Robin Cornelius schrieb: > Can you re run the build with > > ./develop.py build VERBOSE=1 > > and post the actual ld line that is generating the error sure: >> [...] >> Linking CXX executable linux-crash-logger >> cd >> /home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/linux_crash_logger >> && /usr/bin/cmake -P >> CMakeFiles/linux-crash-logger.dir/cmake_clean_target.cmake >> cd >> /home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/linux_crash_logger >> && /usr/bin/g++ -Wall -Wno-sign-compare -Wno-trigraphs -Werror >> -Wno-reorder -DLL_RELEASE=1 -DNDEBUG >> -DLL_RELEASE_WITH_DEBUG_INFO=1 -fPIC -Wl,--as-needed >> "CMakeFiles/linux-crash-logger.dir/linux_crash_logger.o" >> "CMakeFiles/linux-crash-logger.dir/llcrashloggerlinux.o" -o >> linux-crash-logger -rdynamic >> -L/home/das-g/slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llcrashlogger >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llvfs >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llxml >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llmessage >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llmath >> -L/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llcommon >> -Wl,-Bstatic -lllcrashlogger -lllvfs -lllxml -lllmessage -lllvfs >> -lllmath -lllcommon -Wl,-Bdynamic -latk-1.0 -lgdk-x11-2.0 >> -lgdk_pixbuf-2.0 -lXinerama -lglib-2.0 -lgmodule-2.0 -lgobject-2.0 >> -lgthread-2.0 -lgtk-x11-2.0 -lpango-1.0 -lpangoft2-1.0 -lpangox-1.0 >> -lpangoxft-1.0 -ldb-4.2 -lboost_signals-mt -lcurl -lcares -lssl >> -lcrypto -lxmlrpc-epi -laprutil-1 -lapr-1 -lexpat -lz >> /home/das-g/slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: >> undefined reference to `FT_Realloc' >> /home/das-g/slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: >> undefined reference to `FT_Alloc' >> /home/das-g/slsrc/svn/trunk/linden/indra/../libraries/i686-linux/lib_release_client/libpangoft2-1.0.so: >> undefined reference to `FT_Free' >> [...] only ... no 'ld' in there. They seem to call it via g++. > and also can > I have a look at your indra/CMakeCache.txt file. It will be the last > thing before all the errors spit out. ./linden/indra/viewer-linux-i686/CMakeCache.txt attached. Is that the correct one? Boroondas -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686 # It was generated by CMake: /usr/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUI's for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //Library is used for both debug and optimized links /home/das-g/slsrc/svn/trunk/linden/libraries/i686-linux/lib_release_client/libfmod-3.75.so_LINK_TYPE:STATIC=general //Path to artwork files. ARTWORK_DIR:PATH=/home/das-g/slsrc/svn/trunk/linden/indra/newview //Path to a program. BISON:FILEPATH=/usr/bin/bison //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //For backwards compatibility, what version of CMake commands and // syntax should this version of CMake allow. CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 //No help, variable specified on the command line. CMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //Supported build types. CMAKE_CONFIGURATION_TYPES:STRING=RelWithDebInfo;Release;Debug //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=' ' //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. // CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //C compiler. CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc //Flags for C compiler. CMAKE_C_FLAGS:STRING=' ' //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. // CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //Path to a program. CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/gmake //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when using shared libraries. // CMAKE_SKIP_RPATH:BOOL=NO //If true, cmake will use relative paths in makefiles and projects. // CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE //Single output directory for building all executables. EXECUTABLE_OUTPUT_PATH:PATH= //Path to a program. FLEX:FILEPATH=/usr/bin/flex //Use closed source FMOD sound library. FMOD:BOOL=ON //Path to a file. FMOD_INCLUDE_DIR:PATH=/home/das-g/slsrc/svn/trunk/linden/indra/../libraries/include //Path to a library. FMOD_LIBRARY_DEBUG:FILEPATH=/home/das-g/slsrc/svn/trunk/linden/libraries/i686-linux/lib_release_client/libfmod-3.75.so //Path to a library. FMOD_LIBRARY_RELEASE:FILEPATH=/home/das-g/slsrc/svn/trunk/linden/libraries/i686-linux/lib_release_client/libfmod-3.75.so //Target Grid GRID:STRING=agni //Build with GStreamer streaming media support. GSTREAMER:BOOL=ON //Path to a program. GXX:FILEPATH=/usr/bin/g++ //Generate install target. INSTALL:BOOL=OFF //Single output directory for building all libraries. LIBRARY_OUTPUT_PATH:PATH= //Location of prebuilt libraries. LIBS_PREBUILT_DIR:PATH=/home/das-g/slsrc/svn/trunk/linden/indra/../libraries //Path to a program. M4:FILEPATH=/usr/bin/m4 //Enable Mozilla support in the viewer (requires llmozlib library). // MOZLIB:BOOL=ON //Path to a file. OPENGL_INCLUDE_DIR:PATH=/usr/include //Path to a library. OPENGL_gl_LIBRARY:FILEPATH=/usr/lib/libGL.so //Path to a library. OPENGL_glu_LIBRARY:FILEPATH=/usr/lib/libGLU.so //Path to a file. OPENGL_xmesa_INCLUDE_DIR:PATH=/usr/include //Add a package target that builds an installer package. PACKAGE:BOOL=OFF //Path to a program. PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.5 //Path to a program. SCP_EXECUTABLE:FILEPATH=/usr/bin/scp //No help, variable specified on the command line. SERVER:BOOL=FALSE //No help, variable specified on the command line. STANDALONE:BOOL=FALSE //Value Computed by CMake SecondLife_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686 //Value Computed by CMake SecondLife_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra //No help, variable specified on the command line. UNATTENDED:BOOL=FALSE //No help, variable specified on the command line. VIEWER:BOOL=TRUE //The name of the viewer executable to create. VIEWER_BINARY_NAME:STRING=secondlife-bin //Viewer Channel Name VIEWER_CHANNEL:STRING=Developer //Fake login channel for A/B Testing VIEWER_LOGIN_CHANNEL:STRING=Developer //Path to a file. X11_X11_INCLUDE_PATH:PATH=/usr/include //Path to a library. X11_X11_LIB:FILEPATH=/usr/lib/libX11.so //Path to a library. X11_Xext_LIB:FILEPATH=/usr/lib/libXext.so //Path to a file. X11_Xlib_INCLUDE_PATH:PATH=/usr/include //Path to a file. X11_Xutil_INCLUDE_PATH:PATH=/usr/include //Dependencies for the target fmodwrapper_LIB_DEPENDS:STATIC=/home/das-g/slsrc/svn/trunk/linden/libraries/i686-linux/lib_release_client/libfmod-3.75.so;/home/das-g/slsrc/svn/trunk/linden/libraries/i686-linux/lib_release_client/libfmod-3.75.so; //Value Computed by CMake linux_crash_logger_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/linux_crash_logger //Value Computed by CMake linux_crash_logger_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/linux_crash_logger //Value Computed by CMake llaudio_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llaudio //Dependencies for the target llaudio_LIB_DEPENDS:STATIC=vorbisenc;vorbisfile;vorbis;ogg; //Value Computed by CMake llaudio_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llaudio //Value Computed by CMake llcharacter_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llcharacter //Dependencies for target llcharacter_LIB_DEPENDS:STATIC= //Value Computed by CMake llcharacter_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llcharacter //Value Computed by CMake llcommon_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llcommon //Dependencies for the target llcommon_LIB_DEPENDS:STATIC=aprutil-1;db-4.2;apr-1;expat;z; //Value Computed by CMake llcommon_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llcommon //Value Computed by CMake llcrashlogger_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llcrashlogger //Dependencies for target llcrashlogger_LIB_DEPENDS:STATIC= //Value Computed by CMake llcrashlogger_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llcrashlogger //Value Computed by CMake llimage_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llimage //Dependencies for the target llimage_LIB_DEPENDS:STATIC=jpeg;png12;z; //Value Computed by CMake llimage_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llimage //Value Computed by CMake llimagej2coj_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llimagej2coj //Dependencies for the target llimagej2coj_LIB_DEPENDS:STATIC=openjpeg; //Value Computed by CMake llimagej2coj_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llimagej2coj //Value Computed by CMake llinventory_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llinventory //Dependencies for target llinventory_LIB_DEPENDS:STATIC= //Value Computed by CMake llinventory_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llinventory //Value Computed by CMake llmath_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llmath //Dependencies for target llmath_LIB_DEPENDS:STATIC= //Value Computed by CMake llmath_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llmath //Value Computed by CMake llmedia_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llmedia //Dependencies for the target llmedia_LIB_DEPENDS:STATIC=gobject-2.0;gmodule-2.0;dl;gthread-2.0;rt;glib-2.0; //Value Computed by CMake llmedia_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llmedia //Value Computed by CMake llmessage_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llmessage //Dependencies for the target llmessage_LIB_DEPENDS:STATIC=curl;cares;ssl;crypto;xmlrpc-epi; //Value Computed by CMake llmessage_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llmessage //Value Computed by CMake llprimitive_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llprimitive //Dependencies for target llprimitive_LIB_DEPENDS:STATIC= //Value Computed by CMake llprimitive_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llprimitive //Value Computed by CMake llrender_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llrender //Dependencies for target llrender_LIB_DEPENDS:STATIC= //Value Computed by CMake llrender_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llrender //Value Computed by CMake llui_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llui //Dependencies for target llui_LIB_DEPENDS:STATIC= //Value Computed by CMake llui_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llui //Value Computed by CMake llvfs_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llvfs //Dependencies for target llvfs_LIB_DEPENDS:STATIC= //Value Computed by CMake llvfs_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llvfs //Value Computed by CMake llwindow_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llwindow //Dependencies for target llwindow_LIB_DEPENDS:STATIC= //Value Computed by CMake llwindow_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llwindow //Value Computed by CMake llxml_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/llxml //Dependencies for the target llxml_LIB_DEPENDS:STATIC=boost_signals-mt;expat; //Value Computed by CMake llxml_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/llxml //Dependencies for target lscript_compile_LIB_DEPENDS:STATIC= //Dependencies for target lscript_execute_LIB_DEPENDS:STATIC= //Dependencies for target lscript_library_LIB_DEPENDS:STATIC= //Value Computed by CMake viewer_BINARY_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686/newview //Value Computed by CMake viewer_SOURCE_DIR:STATIC=/home/das-g/slsrc/svn/trunk/linden/indra/newview ######################## # INTERNAL cache entries ######################## //Advanced flag for variable: BISON BISON-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_BUILD_TOOL CMAKE_BUILD_TOOL-ADVANCED:INTERNAL=1 //What is the target build tool cmake is generating for. CMAKE_BUILD_TOOL:INTERNAL=/usr/bin/gmake //This is the directory where this CMakeCahe.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/home/das-g/slsrc/svn/trunk/linden/indra/viewer-linux-i686 //Major version of cmake used to create the current loaded cache // CMAKE_CACHE_MAJOR_VERSION:INTERNAL=2 //Minor version of cmake used to create the current loaded cache // CMAKE_CACHE_MINOR_VERSION:INTERNAL=4 //Major version of cmake used to create the current loaded cache // CMAKE_CACHE_RELEASE_VERSION:INTERNAL=patch 8 //Advanced flag for variable: CMAKE_COLOR_MAKEFILE CMAKE_COLOR_MAKEFILE-ADVANCED:INTERNAL=1 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/usr/bin/cmake //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest //Advanced flag for variable: CMAKE_CXX_COMPILER CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1 CMAKE_CXX_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_COMPILER CMAKE_C_COMPILER-ADVANCED:INTERNAL=1 CMAKE_C_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/usr/bin/ccmake //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL // CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Name of generator. CMAKE_GENERATOR:INTERNAL=Unix Makefiles //Have function connect CMAKE_HAVE_CONNECT:INTERNAL=1 //Have function gethostbyname CMAKE_HAVE_GETHOSTBYNAME:INTERNAL=1 //Have function remove CMAKE_HAVE_REMOVE:INTERNAL=1 //Have function shmat CMAKE_HAVE_SHMAT:INTERNAL=1 //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/home/das-g/slsrc/svn/trunk/linden/indra //Install .so files without execute permission. CMAKE_INSTALL_SO_NO_EXE:INTERNAL=0 //Have library ICE CMAKE_LIB_ICE_HAS_ICECONNECTIONNUMBER:INTERNAL=1 //Advanced flag for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL // CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE // CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=24 //Advanced flag for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/usr/share/cmake //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL // CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE // CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Result of TRY_RUN CMAKE_SIZEOF_VOID_P:INTERNAL=4 //Advanced flag for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/usr/bin/uname //Advanced flag for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Advanced flag for variable: FLEX FLEX-ADVANCED:INTERNAL=1 //Advanced flag for variable: GXX GXX-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE HAVE_CMAKE_SIZEOF_VOID_P:INTERNAL=TRUE //Advanced flag for variable: M4 M4-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_INCLUDE_DIR OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_gl_LIBRARY OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_glu_LIBRARY OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_xmesa_INCLUDE_DIR OPENGL_xmesa_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Advanced flag for variable: PYTHON_EXECUTABLE PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1 //Advanced flag for variable: SCP_EXECUTABLE SCP_EXECUTABLE-ADVANCED:INTERNAL=1 //Have library /usr/lib/libX11.so;/usr/lib/libXext.so X11_LIB_X11_SOLO:INTERNAL=1 //Advanced flag for variable: X11_X11_INCLUDE_PATH X11_X11_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_X11_LIB X11_X11_LIB-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xext_LIB X11_Xext_LIB-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xlib_INCLUDE_PATH X11_Xlib_INCLUDE_PATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: X11_Xutil_INCLUDE_PATH X11_Xutil_INCLUDE_PATH-ADVANCED:INTERNAL=1 From robin.cornelius at gmail.com Mon Sep 8 08:51:16 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 8 08:51:23 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: <48C547FA.1050109@boroon.dasgupta.ch> References: <48C51452.4000305@boroon.dasgupta.ch> <48C547FA.1050109@boroon.dasgupta.ch> Message-ID: On Mon, Sep 8, 2008 at 4:42 PM, Boroondas Gupte wrote: > Hi Robin, > thanks for answering. > What version of cmake are you using cmake --version? From robin.cornelius at gmail.com Mon Sep 8 08:55:33 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 8 08:55:36 2008 Subject: [sldev] [HELP] CMake: Errors when linking linux-crash-logger (undefined reference to `FT_Realloc'/`FT_Alloc'/`FT_Free') In-Reply-To: References: <48C51452.4000305@boroon.dasgupta.ch> <48C547FA.1050109@boroon.dasgupta.ch> Message-ID: On Mon, Sep 8, 2008 at 4:51 PM, Robin Cornelius wrote: > On Mon, Sep 8, 2008 at 4:42 PM, Boroondas Gupte > wrote: >> Hi Robin, >> thanks for answering. >> Sorry just seen 2.4.8 Um not sure what is wrong, but this should fix it Edit linux-crash-logger/CMakeLists.txt Add to the target_link_libraries(linux-crash-logger ... ... the extra entry :- ${FREETYPE_LIBRARIES} Should work Robin From bos at lindenlab.com Mon Sep 8 11:11:49 2008 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Sep 8 11:11:51 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <48C532D5.3050300@kitware.com> References: <48C532D5.3050300@kitware.com> Message-ID: On Mon, Sep 8, 2008 at 7:12 AM, Bill Hoffman wrote: > > I have a RC for CMake 2.6.2. One of the driving forces behind getting out > a new 2.6 release was to build second life (as there are some issues with > 2.6.1). Thanks, Bill. I'll second his request to give this CMake RC a whirl. The 2.6 series fixes several dependency analysis bugs in 2.4.8 (the current minimum version that we support). These bugs can lead to the viewer failing to be rebuilt when libraries it depends on change, which can cause confusion and broken builds. If the 2.6.2 release candidates look solid, we're likely to mandate its use after it's released. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/443c78a1/attachment.htm From monkowsk at watson.ibm.com Mon Sep 8 14:11:57 2008 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Sep 8 14:15:41 2008 Subject: [sldev] 2008 Hippo Award winners announced In-Reply-To: <48C40BCF.5020109@lindenlab.com> References: <48C40BCF.5020109@lindenlab.com> Message-ID: <48C5951D.9060104@watson.ibm.com> I'm honored to be chosed as one of the award recipients. My mother would be particularly proud to hear that I "did the work in a tidy and thoughtful way." :-) Thanks to the Lindens and also to Dzonatas Sol who got me set up running SCons on MS Windows. Mm Alder Liana Holmberg wrote: > Short version > > on the blog. > > Long version > (well > worth reading) on the wiki. > > Many thanks to all of you for your contributions over the last year, and > congrats to the winners! > Liana From poppy at lindenlab.com Mon Sep 8 16:25:46 2008 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Mon Sep 8 16:25:52 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <48C5B47A.6000107@lindenlab.com> David M Chess wrote: > I don't really understand this scaling argument. In my experience, > neither "push everything everywhere" nor "constantly ask if there's > anything new" scales; what scales is actual pub/sub. In the case of > group IM, messages get pushed by some server (or some cluster of > entities acting as a logical server) to all and only those places where > someone cares. There's some overhead in keeping track of where there > are places that someone cares, but in most use-cases I've seen it's the > approach that scales the best. Do you have any references / links / copypasta / personal stories on this kind of architecture research? I've been hungering for scalability research lately, and been surprised by much of what I've read. I would assume polling with caching would be much faster than pub/sub because you can use much dumber machinery, but I've also not investigated too many message queuing systems (I also don't work directly on IM). I can't speak for others on this list, but if you cook up a scalability resource mail you've got an audience of at least one ;) + poppy From secret.argent at gmail.com Mon Sep 8 18:06:28 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Sep 8 18:05:40 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <13A60815-4370-475A-97A1-F4A45733D2D0@gmail.com> On 2008-09-08, at 10:00, David M Chess wrote: > Just as a datapoint, I as a private Resident would be quite unhappy > with a change to the group system such that I had to explicitly > "join" the Group IM channel for all my chat groups once per logon > (say) in order to see the Group IM. What if the group owner had to explicitly create a chat channel, and you had to explicitly join it, once, after you joined the group? From dahliatrimble at gmail.com Mon Sep 8 18:49:42 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Mon Sep 8 18:49:44 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080908010010.0E34E113ABF@stupor.lindenlab.com> Message-ID: On Mon, Sep 8, 2008 at 8:00 AM, David M Chess wrote: > > ....... > > > > > But of course we also need to find a solution to support the existing > > group model with those huge groups. > > BTW, what are the actual numbers for the bigger ones? > > > Some random data points: Money Island VIP (raffle) 9984, Fashion > Consolidated (open) 9009, The Wild Coast (pay to join) 5640, Eightbar > (invitation only) 4600, Lucky Money Chair (open) 4529, Scripters of Second > Life (geeks lol) 1974. > I'm not sure of the relevance to this discussion, but I've often been intrigued by some of the user numbers I see on IRC networks. Here's a quick sample taken a moment ago from freenode: Total channels:5197 Top 3 channels by *currently logged in* users: #ubuntu 1362 #gentoo 933 #debian 819 What does this mean, other than freenode is dominated by geeks? It could mean that they have solved some of the scalability problems with the IRC model and it can serve as a reference. > > > So pluggability might be key and the question is how we can support > > both: Some not so secure environment where you maybe can simply join > > some non-SL IM system like Jabber or IRC without further identity > > check > > > Presumably that can be done by just embedding an IRC or Jabber client into > some viewer. Or just running it in a different process on the same machine. > :) No OGP implications, I don't think. I don't see a strong use-case for > it, myself; why should an SL viewer contain a way for me to chat with random > people whos RL and SL identities I don't know? We already have programs for > that. > I'd love to see an IRC client built into the viewer. Currently I can use a web based irc client inside the viewer's browser window, but it takes far more screen real estate than it needs. Then again, the communicate window also takes far more screen real estate than it needs :( -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080908/b37f213d/attachment.htm From steven.harrison at gmail.com Mon Sep 8 19:03:37 2008 From: steven.harrison at gmail.com (Steven Harrison) Date: Mon Sep 8 19:03:40 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <13A60815-4370-475A-97A1-F4A45733D2D0@gmail.com> References: <13A60815-4370-475A-97A1-F4A45733D2D0@gmail.com> Message-ID: <2be42460809081903l4108d8adxef0c767fd9790481@mail.gmail.com> 2008/9/8 David M Chess : > > what scales is actual pub/sub. *waves to David* I think that while pub/sub model does scale (I'm specifically thinking of subscribers to an RSS feed, or something along the lines of Twitter), is it a suitable architecture choice for group IM conferencing? Wouldn't something more like IRC (as Dahlia mentions) be more appropriate? However, I think that pub/sub could easily be done with HTTP and RSS, but adding in some kind of IRC-esque functionality would take a lot more work, 2008/9/8 Argent Stonecutter : > > What if the group owner had to explicitly create a chat channel, and you had > to explicitly join it, once, after you joined the group? > Yes, and it could be done through the client preferences panel with a couple of radio buttons like so: O Join no group chats on login O Join all group chats on login O Join specific groups on login: O Group 1 O Group 2 ... O Group n If you keep it on one tab in the preferences panel, you're not flipping through one page on each group that you belong to turn the group chat on or off. -- Steven Harrison From bristle2005 at yahoo.com Mon Sep 8 19:52:43 2008 From: bristle2005 at yahoo.com (Bristle) Date: Mon Sep 8 19:52:45 2008 Subject: [sldev][ANN] i have created a web site about sims Message-ID: <122297.5019.qm@web52107.mail.re2.yahoo.com> I created a new site http://sim.mischiefworks.net. Right now it is for Second Life clones; I will add Project Darkstar and maybe OpenCroquet. It is not a development site but rather a place where people can get some of the questions answered and where we can do testing. From aimee at ama-zing.co.uk Mon Sep 8 19:30:36 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Mon Sep 8 19:56:32 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <48C532D5.3050300@kitware.com> References: <48C532D5.3050300@kitware.com> Message-ID: On 8 Sep 2008, at 15:12, Bill Hoffman wrote: > Hi folks, > > I have a RC for CMake 2.6.2. One of the driving forces behind > getting out a new 2.6 release was to build second life (as there are > some issues with 2.6.1). This release should address all of the > remaining SL issues. Please give it a try and let me know if you > find any new problems. Hi Bill, I do have one remaining issue. When using the 2.6.2 RC with Xcode 3.1 on the Mac, the appropriate -g and -O flags aren't getting passed through so when selecting Debug, or RelWithDebugInfo, it's getting built without debug symbols, it works fine with 2.4.8. Aimee. From gareth at litesim.com Tue Sep 9 02:11:38 2008 From: gareth at litesim.com (Gareth Nelson) Date: Tue Sep 9 02:11:43 2008 Subject: [sldev] firefox plugin Message-ID: <61dbdd7d0809090211q6a8b2321mda3c782df6a8ade6@mail.gmail.com> I've now got a VERY alpha version of my firefox plugin available for download: http://www.litesim.com/blog/843 From bill.hoffman at kitware.com Tue Sep 9 07:09:55 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Sep 9 07:10:08 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: References: <48C532D5.3050300@kitware.com> Message-ID: <48C683B3.9010607@kitware.com> Aimee Walton wrote: > > Hi Bill, > > I do have one remaining issue. When using the 2.6.2 RC with Xcode 3.1 on > the Mac, the appropriate -g and -O flags aren't getting passed through > so when selecting Debug, or RelWithDebugInfo, it's getting built without > debug symbols, it works fine with 2.4.8. > I am unable to reproduce this issue. Can you send me the project.pbxproj file generated by CMake 2.4 and 2.6? In my tests I see this: GCC_GENERATE_DEBUGGING_SYMBOLS = YES; Also, if I run xcodebuild I see this: Debug: CompileC CxxOnly.build/Debug/CxxOnly.build/Objects-normal/i386/cxxonly.o "/Users/kitware/hoffman/My Tests/CMake/Tests/CxxOnly/cxxonly.cxx" normal i386 c++ com.apple.compilers.gcc.4_0 /usr/bin/gcc-4.0 -x c++ -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -g -O0 -DCMAKE_INTDIR=\"Debug\" -fmessage-length=0 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -O0 -mdynamic-no-pic -F/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/Debug -I/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/Debug/include -I/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/CxxOnly.build/Debug/CxxOnly.build/DerivedSources -c /Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/cxxonly.cxx -o /Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/CxxOnly.build/Debug/CxxOnly.build/Objects-normal/i386/cxxonly.o Release: CompileC CxxOnly.build/Release/CxxOnly.build/Objects-normal/i386/cxxonly.o "/Users/kitware/hoffman/My Tests/CMake/Tests/CxxOnly/cxxonly.cxx" normal i386 c++ com.apple.compilers.gcc.4_0 cd "/Users/kitware/hoffman/My Tests/CMake/Tests/CxxOnly/b" /usr/bin/gcc-4.0 -x c++ -arch i386 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O3 -DCMAKE_INTDIR=\"Release\" -fmessage-length=0 -Wmost -Wno-four-char-constants -Wno-unknown-pragmas -O0 -mdynamic-no-pic -F/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/Release -I/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/Release/include -I/Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/CxxOnly.build/Release/CxxOnly.build/DerivedSources -DNDEBUG -c /Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/cxxonly.cxx -o /Users/kitware/hoffman/My\ Tests/CMake/Tests/CxxOnly/b/CxxOnly.build/Release/CxxOnly.build/Objects-normal/i386/cxxonly.o -Bill From lenglish5 at cox.net Tue Sep 9 09:15:40 2008 From: lenglish5 at cox.net (Lawson English) Date: Tue Sep 9 09:15:45 2008 Subject: [sldev] firefox plugin In-Reply-To: <61dbdd7d0809090211q6a8b2321mda3c782df6a8ade6@mail.gmail.com> References: <61dbdd7d0809090211q6a8b2321mda3c782df6a8ade6@mail.gmail.com> Message-ID: <48C6A12C.5020207@cox.net> Gareth Nelson wrote: > I've now got a VERY alpha version of my firefox plugin available for download: > http://www.litesim.com/blog/843 > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > That is so kool, Gareth. Lawson From grant at lindenlab.com Tue Sep 9 09:44:27 2008 From: grant at lindenlab.com (Grant Linden) Date: Tue Sep 9 09:44:31 2008 Subject: [sldev] RX Office hours - Jacek Antonelli discusses the new, user-interface oriented project called Imprudence Message-ID: <907af5560809090944v13fa2688j525daf758c6946c8@mail.gmail.com> Jacek Antonelli has announced a new, user-interface oriented project called Imprudence as a major fork of the Second Life viewer. She will be our guest host for Rx Office hours and will lead a discussion on the Imprudence Project. http://imprudenceviewer.org/ Thursday September 11th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/df968bae/attachment.htm From edward.artaud at gmail.com Tue Sep 9 12:41:46 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Tue Sep 9 12:41:51 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C5B47A.6000107@lindenlab.com> References: <48C5B47A.6000107@lindenlab.com> Message-ID: There are a lot of tradeoffs of pub/sub vs polling, do a google seach on the words 'pub sub polling' and you'll see many pages on the subject. True pub/sub (as opposed to RESTful pub/sub aka polling) means the server has to be statefully aware of who's subscribed. In practice, not being statefully aware of your subscribers scales better than being aware of them, and as Poppy points out, nice things like caching and ETags/If-Modified-Since/304 Not Modified can be applied in an much more fault tolerant and inexpensive brute force way rather than true pub/sub which typically requires a lot more complex (and harder to maintain systems) to operate at scale. As to the user experience, there's no reason why any of the approaches discussed would have to chage the existing user experience. My point is that something I learned while implementing just such a system several years ago was that group IM with no constraint on number of participants is a totally different beast than 1 to 1 IM. On Mon, Sep 8, 2008 at 4:25 PM, Paul Oppenheim (Poppy Linden) wrote: > David M Chess wrote: >> >> I don't really understand this scaling argument. In my experience, >> neither "push everything everywhere" nor "constantly ask if there's anything >> new" scales; what scales is actual pub/sub. In the case of group IM, >> messages get pushed by some server (or some cluster of entities acting as a >> logical server) to all and only those places where someone cares. There's >> some overhead in keeping track of where there are places that someone cares, >> but in most use-cases I've seen it's the approach that scales the best. > > Do you have any references / links / copypasta / personal stories on this > kind of architecture research? I've been hungering for scalability research > lately, and been surprised by much of what I've read. I would assume polling > with caching would be much faster than pub/sub because you can use much > dumber machinery, but I've also not investigated too many message queuing > systems (I also don't work directly on IM). I can't speak for others on this > list, but if you cook up a scalability resource mail you've got an audience > of at least one ;) > > + poppy > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From me at signpostmarv.name Tue Sep 9 13:02:40 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Sep 9 13:02:41 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> Message-ID: <48C6D660.1090908@signpostmarv.name> Bleh. I have no idea what I'm reading :-s I don't suppose anyone has the time for a 1-on-1 walkthrough ? (I don't need to be taught the language, just need a sherpa to help me find what I'm looking for) ~ Marv Robin Cornelius wrote: > All the search code is pretty much self contained within > newview/llpaneldirevents.cpp > > llpaneldirevents::performQuery() does the query > > The events are received into llpaneldirbrowser.cpp > > LLPanelDirBrowser::processDir****Reply() > > for the various events/people etc searches > > LLPanelDirEvents has LLPanelDirBrowser as a parent class as do each of > the other search panels. > > Robin > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080909/79f97eed/smime.bin From me at signpostmarv.name Tue Sep 9 13:43:41 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue Sep 9 13:43:52 2008 Subject: [sldev] checking how the viewer gets Event info In-Reply-To: References: <48C50C5E.8060408@signpostmarv.name> <9bb32d430809080528h756f7e28qdd3c97eb44498f3f@mail.gmail.com> <48C523B8.3070205@signpostmarv.name> Message-ID: <48C6DFFD.9020603@signpostmarv.name> Clarification. I understand the direction, but not the viewer source code. > Bleh. I have no idea what I'm reading :-s > > I don't suppose anyone has the time for a 1-on-1 walkthrough ? (I don't need to be taught the language, just need a sherpa to help me find what I'm looking for) > > ~ Marv > > Robin Cornelius wrote: >> All the search code is pretty much self contained within >> newview/llpaneldirevents.cpp >> >> llpaneldirevents::performQuery() does the query >> >> The events are received into llpaneldirbrowser.cpp >> >> LLPanelDirBrowser::processDir****Reply() >> >> for the various events/people etc searches >> >> LLPanelDirEvents has LLPanelDirBrowser as a parent class as do each of >> the other search panels. >> >> Robin >> >> > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080909/dacab8a3/smime.bin From labrat.hb at gmail.com Tue Sep 9 14:00:24 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Sep 9 14:00:35 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C5B47A.6000107@lindenlab.com> Message-ID: I think what some people are forgetting in all these statistics and metrics and whatever is that Large Groups in SL do not equal "Large number of people in chat" A group may only be used to send notices out to the members, others people drop chat as soon as they get the first message and do not "join back in" until they feel like chatting. I have 25 groups, of those 25 groups only 5 of them EVER have chat occuring, and of those 5 a very rarely keep all 5 going the entire time I am logged in. On Tue, Sep 9, 2008 at 12:41 PM, Edward Artaud wrote: > There are a lot of tradeoffs of pub/sub vs polling, do a google seach > on the words 'pub sub polling' and you'll see many pages on the > subject. True pub/sub (as opposed to RESTful pub/sub aka polling) > means the server has to be statefully aware of who's subscribed. In > practice, not being statefully aware of your subscribers scales better > than being aware of them, and as Poppy points out, nice things like > caching and ETags/If-Modified-Since/304 Not Modified can be applied in > an much more fault tolerant and inexpensive brute force way rather > than true pub/sub which typically requires a lot more complex (and > harder to maintain systems) to operate at scale. As to the user > experience, there's no reason why any of the approaches discussed > would have to chage the existing user experience. My point is that > something I learned while implementing just such a system several > years ago was that group IM with no constraint on number of > participants is a totally different beast than 1 to 1 IM. > > > On Mon, Sep 8, 2008 at 4:25 PM, Paul Oppenheim (Poppy Linden) > wrote: > > David M Chess wrote: > >> > >> I don't really understand this scaling argument. In my experience, > >> neither "push everything everywhere" nor "constantly ask if there's > anything > >> new" scales; what scales is actual pub/sub. In the case of group IM, > >> messages get pushed by some server (or some cluster of entities acting > as a > >> logical server) to all and only those places where someone cares. > There's > >> some overhead in keeping track of where there are places that someone > cares, > >> but in most use-cases I've seen it's the approach that scales the best. > > > > Do you have any references / links / copypasta / personal stories on this > > kind of architecture research? I've been hungering for scalability > research > > lately, and been surprised by much of what I've read. I would assume > polling > > with caching would be much faster than pub/sub because you can use much > > dumber machinery, but I've also not investigated too many message queuing > > systems (I also don't work directly on IM). I can't speak for others on > this > > list, but if you cook up a scalability resource mail you've got an > audience > > of at least one ;) > > > > + poppy > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/1432b629/attachment-0001.htm From ravenglassrentals at yahoo.com Tue Sep 9 15:48:26 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Sep 9 15:48:29 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <20080909190038.0EBFB41B37A@stupor.lindenlab.com> Message-ID: <608566.98087.qm@web55603.mail.re4.yahoo.com> Re: "Jacek Antonelli has announced a new, user-interface oriented project called mprudence as a major fork of the Second Life viewer. She will be our guest host for Rx Office hours and will lead a discussion on the Imprudence Project.http://imprudenceviewer.org/" I'm highly troubled by the privileging and promotion of certain minority points of view on the viewer that are indicated by this totally unprecedented step involving the Lindens inviting a resident to speak at their office hours, something that I don't think I've ever seen in the history of SL. The "manifesto" about Imprudence is based on the entirely false and incendiary premise that an angry and aggressive minority with a perspective on the viewer of their own making should overthrow the majority, whom Jacek views as supposedly "sullen" or "passive" or "resistant to change" or even "abusive" about changes. Oh, that's ridiculous. Just because we don't want more damage inflicted on an already very long-suffering population that has put up with numerous patches with numerous new gizmos doesn't mean that we are "sullen" and "resistant" to change -- especially when it's obvious the change isn't toward simplification and intuitiveness but is mere replication of the existing issues. Jacek's model of the viewer replicates some of the same Linden geekiness, with things like "camera controls" in your face that the average person simply doesn't need and also in the name of "simplification" or "inventory control" imposes non-intuitive solutions and removes some of the features absolutely vital to business and *commerce* which gets both the Lindens and us paid -- namely the SEARCH buttons and tabs, which have been ENTIRELY removed in Jacek's viewer, in lieu of a lame EXPLORE which implies no commerce but merely passive viewing entertainment. People can argue endlessly about what kind of viewer is needed, but if back of the cosmetics of a viewer change there is still the drop-down blue screen to effect action, it is doomed to clumsiness. That's the sort of entire overhaul that is needed -- getting rid of the blue screen drop-down completely in lieu of other types of interfaces already in the viewer, some as chat, pie menus, etc. I think the Lindens should provide assurances that if some small group is elevated and encouraged to run off and remake the viewer "because everybody else is sullen" supposedly, that they are not free to impose it for mandatory use. That might be self-evident to some; I'd appreciate getting a statement of intent about it from LL. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/68831c4f/attachment.htm From aimee at ama-zing.co.uk Tue Sep 9 15:56:04 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Sep 9 15:56:12 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <48C6C973.6030306@kitware.com> References: <48C532D5.3050300@kitware.com> <48C683B3.9010607@kitware.com> <48C6C973.6030306@kitware.com> Message-ID: <560CAC59-5D21-4488-A358-82F60D73A88F@ama-zing.co.uk> On 9 Sep 2008, at 20:07, Bill Hoffman wrote: > Can you send me the CMakeCache.txt from both? > > Thanks. > > One thing I did notice is that the 2.6.2 one is using -gdwarf-2 for > some reason... > > Also, what version of Xcode are you using? > > -Bill This is on Xcode 3.1 Aimee. -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 # It was generated by CMake: /usr/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUI's for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/universal-darwin/lib_release/libapr-1.a_LINK_TYPE:STATIC=general //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/universal-darwin/lib_release/libaprutil-1.a_LINK_TYPE:STATIC=general //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/universal-darwin/lib_release/libcares.a_LINK_TYPE:STATIC=general //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/universal-darwin/lib_release/liblljpeg.a_LINK_TYPE:STATIC=general //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/universal-darwin/lib_release/libllmozlib2.dylib_LINK_TYPE:STATIC=general //Library is used for both debug and optimized links /Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a_LINK_TYPE:STATIC=general //Path to a library. AGL_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework //Path to a library. APPKIT_LIBRARY:FILEPATH=/System/Library/Frameworks/AppKit.framework //Path to artwork files. ARTWORK_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/newview //Path to a program. BISON:FILEPATH=/usr/bin/bison //Path to a library. CARBON_LIBRARY:FILEPATH=/System/Library/Frameworks/Carbon.framework //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //For backwards compatibility, what version of CMake commands and // syntax should this version of CMake allow. CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 //No help, variable specified on the command line. CMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO //Supported build types. CMAKE_CONFIGURATION_TYPES:STRING=RelWithDebInfo;Release;Debug //C++ compiler CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING=' ' //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. // CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //C compiler CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc //Flags for C compiler. CMAKE_C_FLAGS:STRING=' ' //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. // CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //make program CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/cmakexbuild //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Build architectures for OSX CMAKE_OSX_ARCHITECTURES:STRING=i386 //isysroot used for universal binary support CMAKE_OSX_SYSROOT:STRING=/Developer/SDKs/MacOSX10.4u.sdk //Path to a program. CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. // CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when using shared libraries. // CMAKE_SKIP_RPATH:BOOL=NO //If true, cmake will use relative paths in makefiles and projects. // CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE //Path to a library. COCOA_LIBRARY:FILEPATH=/System/Library/Frameworks/Cocoa.framework //Single output directory for building all executables. EXECUTABLE_OUTPUT_PATH:PATH= //Path to a program. FLEX:FILEPATH=/usr/bin/flex //Use closed source FMOD sound library. FMOD:BOOL=ON //Path to a file. FMOD_INCLUDE_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries/include //Path to a library. FMOD_LIBRARY_DEBUG:FILEPATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a //Path to a library. FMOD_LIBRARY_RELEASE:FILEPATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a //Target Grid GRID:STRING=agni //Generate install target. INSTALL:BOOL=OFF //Path to a library. IOKIT_LIBRARY:FILEPATH=/System/Library/Frameworks/IOKit.framework //Single output directory for building all libraries. LIBRARY_OUTPUT_PATH:PATH= //Location of prebuilt libraries. LIBS_PREBUILT_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries //Path to a program. M4:FILEPATH=/usr/bin/m4 //Enable Mozilla support in the viewer (requires llmozlib library). // MOZLIB:BOOL=ON //Include for OpenGL on OSX OPENGL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenGL.framework //OpenGL lib for OSX OPENGL_gl_LIBRARY:FILEPATH=/System/Library/Frameworks/OpenGL.framework //AGL lib for OSX OPENGL_glu_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework //Add a package target that builds an installer package. PACKAGE:BOOL=OFF //Path to a program. PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python //Build with QuickTime streaming media support. QUICKTIME:BOOL=ON //Path to a library. QUICKTIME_LIBRARY:FILEPATH=/System/Library/Frameworks/QuickTime.framework //Path to a program. SCP_EXECUTABLE:FILEPATH=/opt/local/bin/scp //No help, variable specified on the command line. STANDALONE:BOOL=FALSE //Value Computed by CMake SecondLife_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 //Value Computed by CMake SecondLife_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra //No help, variable specified on the command line. UNATTENDED:BOOL=FALSE //Build Second Life viewer. VIEWER:BOOL=ON //Viewer Channel Name VIEWER_CHANNEL:STRING=Developer //Fake login channel for A/B Testing VIEWER_LOGIN_CHANNEL:STRING=Developer //Dependencies for the target fmodwrapper_LIB_DEPENDS:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a;/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a;/System/Library/Frameworks/Carbon.framework; //Value Computed by CMake llaudio_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llaudio //Dependencies for target llaudio_LIB_DEPENDS:STATIC= //Value Computed by CMake llaudio_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llaudio //Value Computed by CMake llcharacter_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcharacter //Dependencies for target llcharacter_LIB_DEPENDS:STATIC= //Value Computed by CMake llcharacter_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcharacter //Value Computed by CMake llcommon_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcommon //Dependencies for target llcommon_LIB_DEPENDS:STATIC= //Value Computed by CMake llcommon_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcommon //Value Computed by CMake llcrashlogger_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcrashlogger //Dependencies for target llcrashlogger_LIB_DEPENDS:STATIC= //Value Computed by CMake llcrashlogger_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcrashlogger //Value Computed by CMake llimage_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llimage //Dependencies for target llimage_LIB_DEPENDS:STATIC= //Value Computed by CMake llimage_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llimage //Value Computed by CMake llimagej2coj_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llimagej2coj //Dependencies for target llimagej2coj_LIB_DEPENDS:STATIC= //Value Computed by CMake llimagej2coj_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llimagej2coj //Value Computed by CMake llinventory_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llinventory //Dependencies for target llinventory_LIB_DEPENDS:STATIC= //Value Computed by CMake llinventory_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llinventory //Value Computed by CMake llmath_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmath //Dependencies for target llmath_LIB_DEPENDS:STATIC= //Value Computed by CMake llmath_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmath //Value Computed by CMake llmedia_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmedia //Dependencies for target llmedia_LIB_DEPENDS:STATIC= //Value Computed by CMake llmedia_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmedia //Value Computed by CMake llmessage_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmessage //Dependencies for target llmessage_LIB_DEPENDS:STATIC= //Value Computed by CMake llmessage_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmessage //Value Computed by CMake llprimitive_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llprimitive //Dependencies for target llprimitive_LIB_DEPENDS:STATIC= //Value Computed by CMake llprimitive_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llprimitive //Value Computed by CMake llrender_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llrender //Dependencies for target llrender_LIB_DEPENDS:STATIC= //Value Computed by CMake llrender_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llrender //Value Computed by CMake llui_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llui //Dependencies for target llui_LIB_DEPENDS:STATIC= //Value Computed by CMake llui_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llui //Value Computed by CMake llvfs_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llvfs //Dependencies for target llvfs_LIB_DEPENDS:STATIC= //Value Computed by CMake llvfs_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llvfs //Value Computed by CMake llwindow_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llwindow //Dependencies for target llwindow_LIB_DEPENDS:STATIC= //Value Computed by CMake llwindow_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llwindow //Value Computed by CMake llxml_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llxml //Dependencies for target llxml_LIB_DEPENDS:STATIC= //Value Computed by CMake llxml_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llxml //Dependencies for target lscript_compile_LIB_DEPENDS:STATIC= //Dependencies for target lscript_execute_LIB_DEPENDS:STATIC= //Dependencies for target lscript_library_LIB_DEPENDS:STATIC= //Value Computed by CMake mac_crash_logger_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/mac_crash_logger //Value Computed by CMake mac_crash_logger_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/mac_crash_logger //Value Computed by CMake mac_updater_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/mac_updater //Value Computed by CMake mac_updater_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/mac_updater //Value Computed by CMake viewer_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/newview //Value Computed by CMake viewer_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/newview ######################## # INTERNAL cache entries ######################## //Advanced flag for variable: BISON BISON-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_BUILD_TOOL CMAKE_BUILD_TOOL-ADVANCED:INTERNAL=1 //What is the target build tool cmake is generating for. CMAKE_BUILD_TOOL:INTERNAL=/usr/bin/cmakexbuild //This is the directory where this CMakeCahe.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 //Major version of cmake used to create the current loaded cache // CMAKE_CACHE_MAJOR_VERSION:INTERNAL=2 //Minor version of cmake used to create the current loaded cache // CMAKE_CACHE_MINOR_VERSION:INTERNAL=4 //Major version of cmake used to create the current loaded cache // CMAKE_CACHE_RELEASE_VERSION:INTERNAL=patch 8 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/usr/bin/cmake //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/usr/bin/ctest //Advanced flag for variable: CMAKE_CXX_COMPILER CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1 CMAKE_CXX_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_COMPILER CMAKE_C_COMPILER-ADVANCED:INTERNAL=1 CMAKE_C_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/usr/bin/ccmake //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL // CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Name of generator. CMAKE_GENERATOR:INTERNAL=Xcode //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra //Advanced flag for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL // CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE // CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=25 //Advanced flag for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/usr/share/cmake-2.4 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL // CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE // CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO // CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Result of TRY_RUN CMAKE_SIZEOF_VOID_P:INTERNAL=4 //Advanced flag for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/usr/bin/uname //Advanced flag for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Advanced flag for variable: FLEX FLEX-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE HAVE_CMAKE_SIZEOF_VOID_P:INTERNAL=TRUE //Advanced flag for variable: M4 M4-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_INCLUDE_DIR OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_gl_LIBRARY OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_glu_LIBRARY OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: PYTHON_EXECUTABLE PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1 //Advanced flag for variable: QUICKTIME_LIBRARY QUICKTIME_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: SCP_EXECUTABLE SCP_EXECUTABLE-ADVANCED:INTERNAL=1 -------------- next part -------------- # This is the CMakeCache file. # For build in directory: /Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 # It was generated by CMake: /Applications/Development/CMake 2.6-2.app/Contents/bin/cmake # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUI's for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. ######################## # EXTERNAL cache entries ######################## //Path to a library. AGL_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework //Path to a library. APPKIT_LIBRARY:FILEPATH=/System/Library/Frameworks/AppKit.framework //Path to artwork files. ARTWORK_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/newview //Path to a program. BISON:FILEPATH=/usr/bin/bison //Path to a library. CARBON_LIBRARY:FILEPATH=/System/Library/Frameworks/Carbon.framework //Path to a program. CMAKE_AR:FILEPATH=/usr/bin/ar //For backwards compatibility, what version of CMake commands and // syntax should this version of CMake try to support. CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 //No help, variable specified on the command line. CMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO //Supported build types. CMAKE_CONFIGURATION_TYPES:STRING=RelWithDebInfo;Release;Debug //C++ compiler CMAKE_CXX_COMPILER:FILEPATH=/usr/bin/g++ //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //C compiler CMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //Flags used by the linker. CMAKE_EXE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_EXE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_EXE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_INSTALL_NAME_TOOL:FILEPATH=/usr/bin/install_name_tool //Install path prefix, prepended onto install directories. CMAKE_INSTALL_PREFIX:PATH=/usr/local //Path to a program. CMAKE_LINKER:FILEPATH=/usr/bin/ld //make program CMAKE_MAKE_PROGRAM:FILEPATH=/Applications/Development/CMake 2.6-2.app/Contents/bin/cmakexbuild //Flags used by the linker during the creation of modules. CMAKE_MODULE_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_MODULE_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO:STRING= //Path to a program. CMAKE_NM:FILEPATH=/usr/bin/nm //Path to a program. CMAKE_OBJCOPY:FILEPATH=CMAKE_OBJCOPY-NOTFOUND //Path to a program. CMAKE_OBJDUMP:FILEPATH=CMAKE_OBJDUMP-NOTFOUND //Build architectures for OSX CMAKE_OSX_ARCHITECTURES:STRING=i386 //isysroot used for universal binary support CMAKE_OSX_SYSROOT:PATH=/Developer/SDKs/MacOSX10.5.sdk //Path to a program. CMAKE_RANLIB:FILEPATH=/usr/bin/ranlib //Flags used by the linker during the creation of dll's. CMAKE_SHARED_LINKER_FLAGS:STRING= //Flags used by the linker during debug builds. CMAKE_SHARED_LINKER_FLAGS_DEBUG:STRING= //Flags used by the linker during release minsize builds. CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL:STRING= //Flags used by the linker during release builds. CMAKE_SHARED_LINKER_FLAGS_RELEASE:STRING= //Flags used by the linker during Release with Debug Info builds. CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO:STRING= //If set, runtime paths are not added when using shared libraries. CMAKE_SKIP_RPATH:BOOL=NO //Path to a program. CMAKE_STRIP:FILEPATH=/usr/bin/strip //If true, cmake will use relative paths in makefiles and projects. CMAKE_USE_RELATIVE_PATHS:BOOL=OFF //If this value is on, makefiles will be generated without the // .SILENT directive, and all commands will be echoed to the console // during the make. This is useful for debugging only. With Visual // Studio IDE projects all commands are done without /nologo. CMAKE_VERBOSE_MAKEFILE:BOOL=FALSE //Path to a library. COCOA_LIBRARY:FILEPATH=/System/Library/Frameworks/Cocoa.framework //Single output directory for building all executables. EXECUTABLE_OUTPUT_PATH:PATH= //Path to a program. FLEX:FILEPATH=/usr/bin/flex //Use closed source FMOD sound library. FMOD:BOOL=ON //Path to a file. FMOD_INCLUDE_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/include //Path to a library. FMOD_LIBRARY_DEBUG:FILEPATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a //Path to a library. FMOD_LIBRARY_RELEASE:FILEPATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a //Target Grid GRID:STRING=agni //Generate install target. INSTALL:BOOL=OFF //Path to a library. IOKIT_LIBRARY:FILEPATH=/System/Library/Frameworks/IOKit.framework //Single output directory for building all libraries. LIBRARY_OUTPUT_PATH:PATH= //Location of prebuilt libraries. LIBS_PREBUILT_DIR:PATH=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/../libraries //Path to a program. M4:FILEPATH=/usr/bin/m4 //Enable Mozilla support in the viewer (requires llmozlib library). MOZLIB:BOOL=ON //Include for OpenGL on OSX OPENGL_INCLUDE_DIR:PATH=/System/Library/Frameworks/OpenGL.framework //OpenGL lib for OSX OPENGL_gl_LIBRARY:FILEPATH=/System/Library/Frameworks/OpenGL.framework //AGL lib for OSX OPENGL_glu_LIBRARY:FILEPATH=/System/Library/Frameworks/AGL.framework //Add a package target that builds an installer package. PACKAGE:BOOL=OFF //Path to a program. PYTHON_EXECUTABLE:FILEPATH=/usr/bin/python //Build with QuickTime streaming media support. QUICKTIME:BOOL=ON //Path to a library. QUICKTIME_LIBRARY:FILEPATH=/System/Library/Frameworks/QuickTime.framework //Path to a program. SCP_EXECUTABLE:FILEPATH=/opt/local/bin/scp //No help, variable specified on the command line. STANDALONE:BOOL=FALSE //Value Computed by CMake SecondLife_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 //Value Computed by CMake SecondLife_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra //No help, variable specified on the command line. UNATTENDED:BOOL=FALSE //Build Second Life viewer. VIEWER:BOOL=ON //Viewer Channel Name VIEWER_CHANNEL:STRING=Developer //Fake login channel for A/B Testing VIEWER_LOGIN_CHANNEL:STRING=Developer //Dependencies for the target fmodwrapper_LIB_DEPENDS:STATIC=debug;/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a;optimized;/Users/aimee/Documents/Second-Life/Source/viewer_1-21/libraries/universal-darwin/lib_release/libfmod.a;general;/System/Library/Frameworks/Carbon.framework; //Value Computed by CMake llaudio_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llaudio //Dependencies for target llaudio_LIB_DEPENDS:STATIC= //Value Computed by CMake llaudio_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llaudio //Value Computed by CMake llcharacter_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcharacter //Dependencies for target llcharacter_LIB_DEPENDS:STATIC= //Value Computed by CMake llcharacter_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcharacter //Value Computed by CMake llcommon_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcommon //Dependencies for target llcommon_LIB_DEPENDS:STATIC= //Value Computed by CMake llcommon_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcommon //Value Computed by CMake llcrashlogger_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llcrashlogger //Dependencies for target llcrashlogger_LIB_DEPENDS:STATIC= //Value Computed by CMake llcrashlogger_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llcrashlogger //Value Computed by CMake llimage_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llimage //Dependencies for target llimage_LIB_DEPENDS:STATIC= //Value Computed by CMake llimage_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llimage //Value Computed by CMake llimagej2coj_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llimagej2coj //Dependencies for target llimagej2coj_LIB_DEPENDS:STATIC= //Value Computed by CMake llimagej2coj_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llimagej2coj //Value Computed by CMake llinventory_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llinventory //Dependencies for target llinventory_LIB_DEPENDS:STATIC= //Value Computed by CMake llinventory_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llinventory //Value Computed by CMake llmath_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmath //Dependencies for target llmath_LIB_DEPENDS:STATIC= //Value Computed by CMake llmath_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmath //Value Computed by CMake llmedia_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmedia //Dependencies for target llmedia_LIB_DEPENDS:STATIC= //Value Computed by CMake llmedia_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmedia //Value Computed by CMake llmessage_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llmessage //Dependencies for target llmessage_LIB_DEPENDS:STATIC= //Value Computed by CMake llmessage_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llmessage //Value Computed by CMake llprimitive_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llprimitive //Dependencies for target llprimitive_LIB_DEPENDS:STATIC= //Value Computed by CMake llprimitive_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llprimitive //Value Computed by CMake llrender_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llrender //Dependencies for target llrender_LIB_DEPENDS:STATIC= //Value Computed by CMake llrender_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llrender //Value Computed by CMake llui_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llui //Dependencies for target llui_LIB_DEPENDS:STATIC= //Value Computed by CMake llui_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llui //Value Computed by CMake llvfs_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llvfs //Dependencies for target llvfs_LIB_DEPENDS:STATIC= //Value Computed by CMake llvfs_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llvfs //Value Computed by CMake llwindow_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llwindow //Dependencies for target llwindow_LIB_DEPENDS:STATIC= //Value Computed by CMake llwindow_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llwindow //Value Computed by CMake llxml_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/llxml //Dependencies for target llxml_LIB_DEPENDS:STATIC= //Value Computed by CMake llxml_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/llxml //Dependencies for target lscript_compile_LIB_DEPENDS:STATIC= //Dependencies for target lscript_execute_LIB_DEPENDS:STATIC= //Dependencies for target lscript_library_LIB_DEPENDS:STATIC= //Value Computed by CMake mac_crash_logger_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/mac_crash_logger //Value Computed by CMake mac_crash_logger_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/mac_crash_logger //Value Computed by CMake mac_updater_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/mac_updater //Value Computed by CMake mac_updater_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/mac_updater //Value Computed by CMake viewer_BINARY_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386/newview //Value Computed by CMake viewer_SOURCE_DIR:STATIC=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/newview ######################## # INTERNAL cache entries ######################## //Advanced flag for variable: BISON BISON-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_AR CMAKE_AR-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_BUILD_TOOL CMAKE_BUILD_TOOL-ADVANCED:INTERNAL=1 //What is the target build tool cmake is generating for. CMAKE_BUILD_TOOL:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/bin/cmakexbuild //This is the directory where this CMakeCahe.txt was created CMAKE_CACHEFILE_DIR:INTERNAL=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra/build-darwin-i386 //Major version of cmake used to create the current loaded cache CMAKE_CACHE_MAJOR_VERSION:INTERNAL=2 //Minor version of cmake used to create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=6 //Major version of cmake used to create the current loaded cache CMAKE_CACHE_RELEASE_VERSION:INTERNAL=patch 2 RC-3 //Path to CMake executable. CMAKE_COMMAND:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/bin/cmake //Path to cpack program executable. CMAKE_CPACK_COMMAND:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/bin/cpack //Path to ctest program executable. CMAKE_CTEST_COMMAND:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/bin/ctest //Advanced flag for variable: CMAKE_CXX_COMPILER CMAKE_CXX_COMPILER-ADVANCED:INTERNAL=1 CMAKE_CXX_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELEASE CMAKE_CXX_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_CXX_FLAGS_RELWITHDEBINFO CMAKE_CXX_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_COMPILER CMAKE_C_COMPILER-ADVANCED:INTERNAL=1 CMAKE_C_COMPILER_WORKS:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS CMAKE_C_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_DEBUG CMAKE_C_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_MINSIZEREL CMAKE_C_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELEASE CMAKE_C_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_C_FLAGS_RELWITHDEBINFO CMAKE_C_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Result of TRY_COMPILE CMAKE_DETERMINE_CXX_ABI_COMPILED:INTERNAL=TRUE //Result of TRY_COMPILE CMAKE_DETERMINE_C_ABI_COMPILED:INTERNAL=TRUE //Path to cache edit program executable. CMAKE_EDIT_COMMAND:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/bin/ccmake //Executable file format CMAKE_EXECUTABLE_FORMAT:INTERNAL=Unknown //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS CMAKE_EXE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_DEBUG CMAKE_EXE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_MINSIZEREL CMAKE_EXE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELEASE CMAKE_EXE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Name of generator. CMAKE_GENERATOR:INTERNAL=Xcode //Start directory with the top level CMakeLists.txt file for this // project CMAKE_HOME_DIRECTORY:INTERNAL=/Users/aimee/Documents/Second-Life/Source/viewer_1-21/indra //Advanced flag for variable: CMAKE_INSTALL_NAME_TOOL CMAKE_INSTALL_NAME_TOOL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_LINKER CMAKE_LINKER-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MAKE_PROGRAM CMAKE_MAKE_PROGRAM-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS CMAKE_MODULE_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_DEBUG CMAKE_MODULE_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL CMAKE_MODULE_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELEASE CMAKE_MODULE_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO CMAKE_MODULE_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_NM CMAKE_NM-ADVANCED:INTERNAL=1 //number of local generators CMAKE_NUMBER_OF_LOCAL_GENERATORS:INTERNAL=25 //Advanced flag for variable: CMAKE_OBJCOPY CMAKE_OBJCOPY-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_OBJDUMP CMAKE_OBJDUMP-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_RANLIB CMAKE_RANLIB-ADVANCED:INTERNAL=1 //Path to CMake installation. CMAKE_ROOT:INTERNAL=/Applications/Development/CMake 2.6-2.app/Contents/share/cmake-2.6 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_DEBUG CMAKE_SHARED_LINKER_FLAGS_DEBUG-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL CMAKE_SHARED_LINKER_FLAGS_MINSIZEREL-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELEASE CMAKE_SHARED_LINKER_FLAGS_RELEASE-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_SKIP_RPATH CMAKE_SKIP_RPATH-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_STRIP CMAKE_STRIP-ADVANCED:INTERNAL=1 //uname command CMAKE_UNAME:INTERNAL=/usr/bin/uname //Advanced flag for variable: CMAKE_USE_RELATIVE_PATHS CMAKE_USE_RELATIVE_PATHS-ADVANCED:INTERNAL=1 //Advanced flag for variable: CMAKE_VERBOSE_MAKEFILE CMAKE_VERBOSE_MAKEFILE-ADVANCED:INTERNAL=1 //Advanced flag for variable: FLEX FLEX-ADVANCED:INTERNAL=1 //Advanced flag for variable: M4 M4-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_INCLUDE_DIR OPENGL_INCLUDE_DIR-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_gl_LIBRARY OPENGL_gl_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: OPENGL_glu_LIBRARY OPENGL_glu_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: PYTHON_EXECUTABLE PYTHON_EXECUTABLE-ADVANCED:INTERNAL=1 //Advanced flag for variable: QUICKTIME_LIBRARY QUICKTIME_LIBRARY-ADVANCED:INTERNAL=1 //Advanced flag for variable: SCP_EXECUTABLE SCP_EXECUTABLE-ADVANCED:INTERNAL=1 From darien.caldwell at gmail.com Tue Sep 9 15:58:05 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Tue Sep 9 15:58:09 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <608566.98087.qm@web55603.mail.re4.yahoo.com> References: <20080909190038.0EBFB41B37A@stupor.lindenlab.com> <608566.98087.qm@web55603.mail.re4.yahoo.com> Message-ID: <835a5b860809091558l277cb1a8he238d9e93275612f@mail.gmail.com> Well, I can't speak for LL, but It seemed pretty clear to me that they were starting this group because they feel LL isn't receptive to the changes they want to do. In other words "if we can't get LL to do it, we will fork our own viewer." Which is fine. There are a lot of viewers out there now, I learn of new ones every day. And everyone has their own take on how things should be done. In the end people will choose the viewer that works best for their needs. And there's nothing anybody can do to stop that, short of LL refusing connections from anything but their own viewer. I don't get a sense they will move in that direction though. Different Lindens run their office hours in different ways. I do agree it's unique to have a guest speaker, but it's not an unheard of convention in teaching circles. It may boil down to they have nothing more pressing to discuss at the moment. :) On 9/9/08, Random Unsung wrote: > Re: "Jacek Antonelli has announced a new, user-interface oriented project > called mprudence as a major fork of the Second Life viewer. She will be our > guest host for Rx Office hours and will lead a discussion on the Imprudence > Project.http://imprudenceviewer.org/" > > I'm highly troubled by the privileging and promotion of certain minority > points of view on the viewer that are indicated by this totally > unprecedented step involving the Lindens inviting a resident to speak at > their office hours, something that I don't think I've ever seen in the > history of SL. > > The "manifesto" about Imprudence is based on the entirely false and > incendiary premise that an angry and aggressive minority with a perspective > on the viewer of their own making should overthrow the majority, whom Jacek > views as supposedly "sullen" or "passive" or "resistant to change" or even > "abusive" about changes. > > Oh, that's ridiculous. Just because we don't want more damage inflicted on > an already very long-suffering population that has put up with numerous > patches with numerous new gizmos doesn't mean that we are "sullen" and > "resistant" to change -- especially when it's obvious the change isn't > toward simplification and intuitiveness but is mere replication of the > existing issues. Jacek's model of the viewer replicates some of the same > Linden geekiness, with things like "camera controls" in your face that the > average person simply doesn't need and also in the name of "simplification" > or "inventory control" imposes non-intuitive solutions and removes some of > the features absolutely vital to business and *commerce* which gets both the > Lindens and us paid -- namely the SEARCH buttons and tabs, which have been > ENTIRELY removed in Jacek's viewer, in lieu of a lame EXPLORE which implies > no commerce but merely passive viewing entertainment. > > People can argue endlessly about what kind of viewer is needed, but if back > of the cosmetics of a viewer change there is still the drop-down blue screen > to effect action, it is doomed to clumsiness. That's the sort of entire > overhaul that is needed -- getting rid of the blue screen drop-down > completely in lieu of other types of interfaces already in the viewer, some > as chat, pie menus, etc. > > I think the Lindens should provide assurances that if some small group is > elevated and encouraged to run off and remake the viewer "because everybody > else is sullen" supposedly, that they are not free to impose it for > mandatory use. That might be self-evident to some; I'd appreciate getting a > statement of intent about it from LL. > > > > > From jacek.antonelli at gmail.com Tue Sep 9 17:03:31 2008 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Tue Sep 9 17:03:33 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <608566.98087.qm@web55603.mail.re4.yahoo.com> References: <20080909190038.0EBFB41B37A@stupor.lindenlab.com> <608566.98087.qm@web55603.mail.re4.yahoo.com> Message-ID: <105c09f0809091703v412373a7y3eb86b8a01794af0@mail.gmail.com> On Tue, Sep 9, 2008 at 5:48 PM, Random Unsung wrote: > Re: "Jacek Antonelli has announced a new, user-interface oriented project > called mprudence as a major fork of the Second Life viewer. She will be our > guest host for Rx Office hours and will lead a discussion on the Imprudence > Project.http://imprudenceviewer.org/" > > I'm highly troubled by the privileging and promotion of certain minority > points of view on the viewer that are indicated by this totally > unprecedented step involving the Lindens inviting a resident to speak at > their office hours, something that I don't think I've ever seen in the > history of SL. > > The "manifesto" about Imprudence is based on the entirely false and > incendiary premise that an angry and aggressive minority with a perspective > on the viewer of their own making should overthrow the majority, whom Jacek > views as supposedly "sullen" or "passive" or "resistant to change" or even > "abusive" about changes. > > Oh, that's ridiculous. Just because we don't want more damage inflicted on > an already very long-suffering population that has put up with numerous > patches with numerous new gizmos doesn't mean that we are "sullen" and > "resistant" to change -- especially when it's obvious the change isn't > toward simplification and intuitiveness but is mere replication of the > existing issues. Jacek's model of the viewer replicates some of the same > Linden geekiness, with things like "camera controls" in your face that the > average person simply doesn't need and also in the name of "simplification" > or "inventory control" imposes non-intuitive solutions and removes some of > the features absolutely vital to business and *commerce* which gets both the > Lindens and us paid -- namely the SEARCH buttons and tabs, which have been > ENTIRELY removed in Jacek's viewer, in lieu of a lame EXPLORE which implies > no commerce but merely passive viewing entertainment. > > People can argue endlessly about what kind of viewer is needed, but if back > of the cosmetics of a viewer change there is still the drop-down blue screen > to effect action, it is doomed to clumsiness. That's the sort of entire > overhaul that is needed -- getting rid of the blue screen drop-down > completely in lieu of other types of interfaces already in the viewer, some > as chat, pie menus, etc. > > I think the Lindens should provide assurances that if some small group is > elevated and encouraged to run off and remake the viewer "because everybody > else is sullen" supposedly, that they are not free to impose it for > mandatory use. That might be self-evident to some; I'd appreciate getting a > statement of intent about it from LL. > I'm afraid you are misinformed on several points about our project: 1. The goal of the project is not to overthrow anything, nor to impose a new viewer on anyone, nor to make its use mandatory for anyone. 2. The goal of the project is not to implement the design I put forward in the contest. 3. The goal of the project is not to make mere cosmetic changes. 4. The goal of the project is not to remove useful functionality from the viewer. Since you seem to indicate that you have read the manifesto, you must surely be aware that the goal of the project is to make substantial changes to greatly improve usability of the viewer software. We welcome all constructive feedback and insight into how to best meet the needs and desires of users at large. - Jacek From ravenglassrentals at yahoo.com Tue Sep 9 17:50:36 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Sep 9 17:50:39 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <105c09f0809091703v412373a7y3eb86b8a01794af0@mail.gmail.com> Message-ID: <434241.23991.qm@web55607.mail.re4.yahoo.com> No, I'm not "misinformed". You've exposed your hand clearly in the language of the manifesto: " A vast throng of paying customers who want the Viewer to remain constant and familiar. If the Viewer changes, they are forced to spend effort relearning it. The most vocal and abusive users even meet change with sneers and insults That's inciting hatred, and completely misrepresenting the majority of viewers, as I already explained. Who are you to arrogate yourself to deciding what is "better" for the public? The tone of this exercise is really the most arrogant kind of hubris I've seen in a long time. You imply that people who disagree with your strange ideas (like removing SEARCH) are FUDites or Luddites who "can't accept change," when it's merely common sense resisting idiocy. It doesn't *matter* if literally the goal of your project is "not to implement" your particular viewer as it was displayed in Dusan's contest. The *thinking and ideology* that went into your particular viewer bleeds through everywhere in a project like this, as we can see from its manifesto, and is yet another example of how "things that are supposedly purely technological" in fact are deeply, deeply political. The complete absence of search is the first tip-off. Why do you think you and your little group of friends get to decide what is useful for the public? And why are the Lindens promoting this?! It's not at all constructive, it's destructive. You do not not have the public trust in the matter of deciding what is "useful" or "intuitive" for the viewer, Jacek. You've already shown your infinite scorn for the public by the untrue things you've published by "the vast majority". Really, you need to keep your paws off our viewer -- and stop this fake exercise of "soliciting only constructive views" so as to remove any objection to your high-handed takeover. So much damage has already been done to us with Windlight, which really destroyed the use of SL for so many of us; that blisteringly blinding Dazzle was such a disaster, that the Lindens really need to stop inciting destructiveness to their world and the vehicles for viewing it and enhance stability and usability.? Just because some small group comes along and declares enormous scorn for what they claim is a majority view (and how precisely did they measure that?!) and just because they claim they have some "insight" into what is usable doesn't mean they offer anything viable. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/4f3da5e1/attachment.htm From gbrandon at gmail.com Tue Sep 9 19:08:55 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Tue Sep 9 19:08:59 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <434241.23991.qm@web55607.mail.re4.yahoo.com> References: <105c09f0809091703v412373a7y3eb86b8a01794af0@mail.gmail.com> <434241.23991.qm@web55607.mail.re4.yahoo.com> Message-ID: Who suggested there was such a thing as a mandatory viewer? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/d738c9a1/attachment.htm From GordonWendt at gmail.com Tue Sep 9 19:35:44 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Sep 9 19:35:48 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <608566.98087.qm@web55603.mail.re4.yahoo.com> References: <20080909190038.0EBFB41B37A@stupor.lindenlab.com> <608566.98087.qm@web55603.mail.re4.yahoo.com> Message-ID: <493033a70809091935n1086a7c0yf748b54b1b8f4bbc@mail.gmail.com> Note: Random Unsung == Prokofy Neva, this is publicly acknowledged by Prok, I'm saying this only so that nobody gets confused when I refer to Prok by that name and is not meant as a slight on her. Prok, I realize that in your mind I'm already beyond saving as far as saving since I've gone to far to the side of the tyranny of the techies as you have put it several times before but I don't see the huge issue with this. First of all I have yet to see anything by them saying that they want to make it a mandatory viewer so I'd be interested to see quotes and/or a reference for that statement. Secondly I don't see how this is fundamentally different than any other fork, a great example of this is the ESC's viewer which reskinned the entire viewer, removed huge chunks of the old viewer and split in both old functionality in new ways and brand new functionality... and those that have seen my rants know how painful it is for me to actually praise ESC for anything they've done but that's off the topic. On the topic of the office hours I don't know the details of how it was arranged but per the above comments I'd agree that while it's unheard of in SL it's not unprecedented in this type of general situation and I'm somewhat surprised LL hasn't done this before and I hope they will open this up to other people, actually expect if they don't want the appearance of conflict of interest, but until they at least have a chance to clarify the circumstances behind that I'm happy to be inquisitive instead of accusatory. From ravenglassrentals at yahoo.com Tue Sep 9 19:41:09 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Sep 9 19:41:12 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: Message-ID: <418606.15039.qm@web55608.mail.re4.yahoo.com> The Lindens drop down mandatory viewers all the time -- we don't get a choice as to whether we want Windlight (even the dumbed down settings are crippling or not) or whether we want "Showcase" or not or any number of new viewers. That is, sure, someone could go off and use an untrusted third-party viewer and entrust their financial transactions and password to it -- but, um, no thanks. Sooner or later, viewers become mandatory, and it's important not to allow special interests to creep into them to advantage this or that sectarian group at the expense of others. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/3ff28059/attachment-0001.htm From dahliatrimble at gmail.com Tue Sep 9 19:43:43 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Sep 9 19:43:46 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <608566.98087.qm@web55603.mail.re4.yahoo.com> References: <20080909190038.0EBFB41B37A@stupor.lindenlab.com> <608566.98087.qm@web55603.mail.re4.yahoo.com> Message-ID: On Tue, Sep 9, 2008 at 3:48 PM, Random Unsung wrote: (portions removed for the sake of brevity) > > I think the Lindens should provide assurances that if some small group is > elevated and encouraged to run off and remake the viewer "because everybody > else is sullen" supposedly, that they are not free to impose it for > mandatory use. That might be self-evident to some; I'd appreciate getting a > statement of intent about it from LL. > > No! No! No PLEASE dont make me reference the GPL ... awww darn I can't hold back :( http://www.gnu.org/copyleft/gpl.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/c0344cb4/attachment.htm From ravenglassrentals at yahoo.com Tue Sep 9 19:45:40 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Sep 9 19:45:43 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 25 In-Reply-To: <20080910024115.E05AA41B472@stupor.lindenlab.com> Message-ID: <471283.16986.qm@web55605.mail.re4.yahoo.com> Gordon, for the 4th time here now: the issue is not a claim that Jacek is formally making a "mandatory viewer". That's not possible in theory. The problem is that in practice, a forked viewer that gets a privileged bully pulpit like a Linden office hour to amplify its ideas is one that can begin to insinuate certain concepts and principles that the Lindens adapt, sometimes under clamor and agitation from "thecommunity" -- the people who constitute the fake "public" around the office hours who merely represent the technocratically interested parties. The way to prevent something from becoming mandatory is to speak out loudly and clearly when it is only "forked" or "voluntary" or "optional". A viewer that has no SEARCH in it, or imposes CAMERA CONTROLS is a viewer that has an ideology to it that begins to bleed into other projects and it's important to say NO to these things NOW. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/33b26041/attachment.htm From GordonWendt at gmail.com Tue Sep 9 19:48:00 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Sep 9 19:48:03 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 22 In-Reply-To: <418606.15039.qm@web55608.mail.re4.yahoo.com> References: <418606.15039.qm@web55608.mail.re4.yahoo.com> Message-ID: <493033a70809091948j69f2b914r98aa84670da278f6@mail.gmail.com> Umm, yes that's the Lindens who also provide the service so I'm guessing that you aren't referring to them when talking generally about the evils of mandatory viewers. If you're afraid of interests getting in then you shouldn't even be using the official viewers what with all those user created patches, all those features and bug fixes requested by the community on the JIRA and of course these mailing lists (which ironically your using to deride the techies after publicly deriding this mailing list many times on your blog.... hypocrisy anyone?) On Tue, Sep 9, 2008 at 10:41 PM, Random Unsung wrote: > The Lindens drop down mandatory viewers all the time -- we don't get a > choice as to whether we want Windlight (even the dumbed down settings are > crippling or not) or whether we want "Showcase" or not or any number of new > viewers. That is, sure, someone could go off and use an untrusted > third-party viewer and entrust their financial transactions and password to > it -- but, um, no thanks. > > Sooner or later, viewers become mandatory, and it's important not to allow > special interests to creep into them to advantage this or that sectarian > group at the expense of others. From ravenglassrentals at yahoo.com Tue Sep 9 19:49:43 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Tue Sep 9 19:49:46 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 25 In-Reply-To: <20080910024115.E05AA41B472@stupor.lindenlab.com> Message-ID: <525510.78169.qm@web55601.mail.re4.yahoo.com> Re: " a great example of this is the ESC's viewer which reskinned the entire viewer, removed huge chunks of the old viewer and split in both old functionality in new ways and brand new functionality..." Glad you mentioned this example, as it is a perfect illustration of my point. The ESC viewer, for which LL was paid a license fee, is optional. Yet had it been used by the original "million signups," it would have had a dramatic impact on the world and its economy and would have driven traffic specifically to ESC-advertised properties welded into the viewer, and would have essentially been a way for one large company to buy the economy and skew it. That didn't happen merely because the CBS show didn't get that many sign-ups. More to the point, however, the ESC viewer contained a nerfing of SEARCH that got rid of the search button at the bottom completely, replacing it with a search box at the top, so that reaching tabbed searches couldn't happen except with three separate clicks -- the search box gives you SEARCH ALL which is a huge grab bag. And it was precisely that bad model for SEARCH that ended up today in the Lindens' viewer -- they copied it wholesale. The only thing is they left the vestiges of the old search button on the bottom so that it's not quite as crippling a situation as the ESC viewer, which I heavily critiqued for this reason. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080909/5f4bd45e/attachment.htm From GordonWendt at gmail.com Tue Sep 9 19:57:17 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Sep 9 19:57:21 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 25 In-Reply-To: <471283.16986.qm@web55605.mail.re4.yahoo.com> References: <20080910024115.E05AA41B472@stupor.lindenlab.com> <471283.16986.qm@web55605.mail.re4.yahoo.com> Message-ID: <493033a70809091957i7838f2a8o5090f006085a7f7f@mail.gmail.com> I agree wholeheartedly with the latter part of that, and incidentally they wouldn't be the first ones as anyone who's been around and especially those that have been on this list and seen my input on the whole ESC special treatment debacle knows, however while I am concerned about them getting the office hours I'm not yet prepared to make that jump. Hopefully a Linden will grace us with their presence and clarify and I would hope that this is the start of a trend (I'm sure one you'd probably criticize as being a favortism fest for LL's "friends") of guests from all groups, even you (I don't agree with you... at all but I'd be interested if it happened), representing sl as guest hosts on their topic du jour but I guess that's a topic for another time. Note: Prok, your reply (a great example of this...) came in halfway through this post so this post is a response just to your quoted post below. On Tue, Sep 9, 2008 at 10:45 PM, Random Unsung wrote: > Gordon, for the 4th time here now: the issue is not a claim that Jacek is > formally making a "mandatory viewer". That's not possible in theory. > > The problem is that in practice, a forked viewer that gets a privileged > bully pulpit like a Linden office hour to amplify its ideas is one that can > begin to insinuate certain concepts and principles that the Lindens adapt, > sometimes under clamor and agitation from "thecommunity" -- the people who > constitute the fake "public" around the office hours who merely represent > the technocratically interested parties. > > The way to prevent something from becoming mandatory is to speak out loudly > and clearly when it is only "forked" or "voluntary" or "optional". A viewer > that has no SEARCH in it, or imposes CAMERA CONTROLS is a viewer that has an > ideology to it that begins to bleed into other projects and it's important > to say NO to these things NOW. From aimee at ama-zing.co.uk Tue Sep 9 20:28:01 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Sep 9 20:28:05 2008 Subject: [sldev] Re: Viewer forks (was: SLDev Digest, Vol 21, Issue 25) In-Reply-To: <471283.16986.qm@web55605.mail.re4.yahoo.com> References: <471283.16986.qm@web55605.mail.re4.yahoo.com> Message-ID: <5E4264B6-1444-4A0E-B69F-B8582E605875@ama-zing.co.uk> (Can we remember to set a message title when posting please? Thanks :) On 10 Sep 2008, at 03:45, Random Unsung wrote: > The way to prevent something from becoming mandatory is to speak out > loudly and clearly when it is only "forked" or "voluntary" or > "optional". A viewer that has no SEARCH in it, or imposes CAMERA > CONTROLS is a viewer that has an ideology to it that begins to bleed > into other projects and it's important to say NO to these things NOW. Following that logic we should all be extremely concerned and protesting the release of the SLim client, as it suggests that Linden Lab intend to remove the graphical world view from the standard viewer in favor of a text only client in future. Aimee T. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/f2c510b0/attachment.htm From tom at streamsense.net Wed Sep 10 02:33:00 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Sep 10 02:33:10 2008 Subject: [sldev] Problem with script errors Message-ID: <48C7944C.1030602@streamsense.net> I am posting this here since this jira outlines a potential exploit with the way SL handles errors from scripts; I have only classified the Jira as a "new feature" since it's not a bug as such.. should I upgrade it? ==== http://jira.secondlife.com/browse/SVC-3044 Currently, script errors in second life are handled as follows: 1 Script errors are reported to the script warning/error window 2 As default, script errors are also outputted into local chat 3 If you create a script to listen on channel 0, "script error" messages appear to becoming from a NULL_KEY 4 If an object on a hud has created an error, there is no way for a non-linden to know where the error came from 5 Sending chat to DEBUG_CHANNEL will currently output into chat regardless of the client configuration This presents the following issues: - Issues 2, 3 and 4 combined present a very large exploitable weakness. I could go into a crowded sim, create a prim with twenty or so scripts designed to error and reset in quick succession, and attach it to my hud. Any user with default settings would receive a massive flood of debug spam in their chat window, and no script or client will be able to detect which avatar is causing the spam. - Currently there is no viable way for an object / product to self-diagnose errors. This is basic functionality which should be present. The fix I suggest is as follows: - Allow scripts to listen on CHANNEL_DEBUG for script errors, and ensure that the KEY of the offending object is passed. From secret.argent at gmail.com Wed Sep 10 05:24:44 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 10 05:23:53 2008 Subject: [sldev] Re: Viewer forks (was: SLDev Digest, Vol 21, Issue 25) In-Reply-To: <5E4264B6-1444-4A0E-B69F-B8582E605875@ama-zing.co.uk> References: <471283.16986.qm@web55605.mail.re4.yahoo.com> <5E4264B6-1444-4A0E-B69F-B8582E605875@ama-zing.co.uk> Message-ID: On 2008-09-09, at 22:28, Aimee Walton wrote: > Following that logic we should all be extremely concerned and > protesting the release of the SLim client, as it suggests that > Linden Lab intend to remove the graphical world view from the > standard viewer in favor of a text only client in future. Some of us ARE raising questions about the SLim client on technical grounds, because it changes a lot of assumptions about IM and about LL's decision to bypass XMPP, and about what it implies about the relationship of IM and SL and Voice for the future. From secret.argent at gmail.com Wed Sep 10 05:28:18 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Sep 10 05:27:26 2008 Subject: [sldev] Problem with script errors In-Reply-To: <48C7944C.1030602@streamsense.net> References: <48C7944C.1030602@streamsense.net> Message-ID: <60F305E1-606E-4CB1-ACEE-47915760E888@gmail.com> On 2008-09-10, at 04:33, Thomas Grimshaw wrote: > 2 As default, script errors are also outputted into local chat Are you sure about that? I remember having to explicitly turn that on, and most people don't seem to see script errors in chat based on their reactions when I ask them to fix their AO to stop spamming error messages because they took "Sexy Walk 3" out but didn't update the notecard. From robin.cornelius at gmail.com Wed Sep 10 05:46:01 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Sep 10 05:46:06 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <48C532D5.3050300@kitware.com> References: <48C532D5.3050300@kitware.com> Message-ID: On Mon, Sep 8, 2008 at 3:12 PM, Bill Hoffman wrote: > Hi folks, > > I have a RC for CMake 2.6.2. One of the driving forces behind getting out a > new 2.6 release was to build second life (as there are some issues with > 2.6.1). This release should address all of the remaining SL issues. Please > give it a try and let me know if you find any new problems. > Looking good on my Debian Lenny standalone builds ;-) Due to complications of my packaging, i have created a .deb of cmake-2.6.2-RC3 on my repository so that my auto-builders can find it. For any one who wants it for debian/ubuntu its under http://apt.byteme.org.uk/pool/main/c/cmake/ for amd64 and i386 (or just add my repository to /etc/apt/source.list) Unfortunately Lenny (and sid) both currently have 2.6.0 which means building out of the box on debian will currently be broken, hence adding to my repository. Robin From danteferret at gmail.com Wed Sep 10 07:41:16 2008 From: danteferret at gmail.com (Dante Tucker) Date: Wed Sep 10 07:41:18 2008 Subject: [sldev] Problem with script errors In-Reply-To: <60F305E1-606E-4CB1-ACEE-47915760E888@gmail.com> References: <48C7944C.1030602@streamsense.net> <60F305E1-606E-4CB1-ACEE-47915760E888@gmail.com> Message-ID: <4d211a610809100741p75f61eedh1636e74a685762d1@mail.gmail.com> Well I can also say script error output to local chat is not a default. But points 3 and 4 of his are still bugs. Just remove points 2 and 5 and your all good. On Wed, Sep 10, 2008 at 8:28 AM, Argent Stonecutter wrote: > On 2008-09-10, at 04:33, Thomas Grimshaw wrote: > >> 2 As default, script errors are also outputted into local chat >> > > Are you sure about that? I remember having to explicitly turn that on, and > most people don't seem to see script errors in chat based on their reactions > when I ask them to fix their AO to stop spamming error messages because they > took "Sexy Walk 3" out but didn't update the notecard. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/df7e07e8/attachment.htm From chess at us.ibm.com Wed Sep 10 08:00:19 2008 From: chess at us.ibm.com (David M Chess) Date: Wed Sep 10 08:00:55 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: >From: "Paul Oppenheim (Poppy Linden)" > >David M Chess wrote: >> I don't really understand this scaling argument. In my experience, >> neither "push everything everywhere" nor "constantly ask if there's >> anything new" scales; what scales is actual pub/sub. In the case of >> group IM, messages get pushed by some server (or some cluster of >> entities acting as a logical server) to all and only those places where >> someone cares. There's some overhead in keeping track of where there >> are places that someone cares, but in most use-cases I've seen it's the >> approach that scales the best. > >Do you have any references / links / copypasta / personal stories on this kind of architecture research? I've been >hungering for scalability research lately, and been surprised by much of what I've read. I would assume polling with >caching would be much faster than pub/sub because you can use much dumber machinery, but I've also not investigated >too many message queuing systems (I also don't work directly on IM). I can't speak for others on this list, but if >you cook up a scalability resource mail you've got an audience of at least one ;) I will look around for some references; in my experience actual practical stories about how stuff works get published far too rarely. :) My most recent experience with this is in some distributed computing middleware (IBM WebSphere VE, nee XD). The exact situation there is somewhat radically different, so the details of the solution we used aren't really relevant, but the basic calculation is. If you have (say) a group with 1000 members, spread across 10 ADs, where at a typical time 100 of those members are logged in, involving 6 of the ADs, with a typical peak rate of 1 message every two seconds, and you don't want to impose an additional latency of more than 5 seconds, say (group IM with even just a 5-second delay would be unusable imho, but we'll stick that in to get a lower bound), the choices seem to be: (1) Have 100 polls against the message store every 5 seconds, for a 20-hits-per-second load just for this one rather typical medium-sized group, or (2) Send one message to each of the 10 ADs every two seconds, four of which are unnecessary, or (3) Keep track of the fact that four of those ADs don't have anyone in the group logged in right now (which involves some messaging overhead to keep track of that, but it's really pretty simple), and send one message to the 6 actually involved ADs every two seconds. If people log in and our much oftener than they send messages, then the who-is-on tracking in (3) might make (2) the most efficient choice, but I tend to think that (3) generally wins. Depending on just what you mean by "with caching", (1) is pretty bad; you might insert a nearby cache between the viewer and the message store in (1), but even in the best case (one cache per AD, say) you still have more than three polls per second against the caches (16.7 every five seconds) and more than one poll per second (six every five seconds) against the message store, just for this one group. This can be made better by polling less often from the caches (but then you get unacceptable chatlag), or by pushing from the message center to the caches (but then we're really doing (2) or (3), not (1)). This is all very top-of-the-head, so I may have overlooked something key, or I may have misunderstood what you meant by "polling with caching", or I may have just divided wrong. :) But hopefully it's at least slightly interesting. :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/19227d99/attachment.htm From tom at streamsense.net Wed Sep 10 08:45:21 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed Sep 10 08:45:34 2008 Subject: [sldev] Problem with script errors In-Reply-To: <4d211a610809100741p75f61eedh1636e74a685762d1@mail.gmail.com> References: <48C7944C.1030602@streamsense.net> <60F305E1-606E-4CB1-ACEE-47915760E888@gmail.com> <4d211a610809100741p75f61eedh1636e74a685762d1@mail.gmail.com> Message-ID: <48C7EB91.6010907@streamsense.net> Dante Tucker wrote: > Well I can also say script error output to local chat is not a default. > > But points 3 and 4 of his are still bugs. Just remove points 2 and 5 and > your all good. > Point 5 is a confirmed bug, imported in the jira, and is unrelated to point 2: http://jira.secondlife.com/browse/VWR-199 Regarding point 2.. I have never had to activate the "output to local" option, in fact i don't even know where to find it :) But I do use the release candidate clients extensively, perhaps only the RC has this as default? Tom. From gbrandon at gmail.com Wed Sep 10 08:58:04 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Sep 10 08:58:08 2008 Subject: [sldev] Problem with script errors In-Reply-To: <48C7EB91.6010907@streamsense.net> References: <48C7944C.1030602@streamsense.net> <60F305E1-606E-4CB1-ACEE-47915760E888@gmail.com> <4d211a610809100741p75f61eedh1636e74a685762d1@mail.gmail.com> <48C7EB91.6010907@streamsense.net> Message-ID: >> 4 If an object on a hud has created an error, there is no way for a non-linden to know where the error came from I wouldn't count on a Linden being more able to find the source either. Script errors are anonymous to clients, too. You get chat messages from NULL_KEY. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/b59531b2/attachment.htm From chess at us.ibm.com Wed Sep 10 09:12:22 2008 From: chess at us.ibm.com (David M Chess) Date: Wed Sep 10 09:13:30 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: > From: Argent Stonecutter >On 2008-09-08, at 10:00, David M Chess wrote: >> Just as a datapoint, I as a private Resident would be quite unhappy >> with a change to the group system such that I had to explicitly >> "join" the Group IM channel for all my chat groups once per logon >> (say) in order to see the Group IM. > >What if the group owner had to explicitly create a chat channel, and >you had to explicitly join it, once, after you joined the group? As Steven says, at that point it's a UI/Viewer issue; the person creating the group gets a "should this group have an IM channel?" checkbox (and we can discuss what the default is), and if there is one then when I join the group I get to decide whether to join it or not (or maybe I don't, even, and I just automatically join it). Works for me. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/fbb814fe/attachment-0001.htm From tateru.nino at gmail.com Wed Sep 10 09:18:46 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Sep 10 09:19:11 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <48C7F366.3090504@weblogsinc.com> David M Chess wrote: > > >From: "Paul Oppenheim (Poppy Linden)" > > > >David M Chess wrote: > >> I don't really understand this scaling argument. In my experience, > >> neither "push everything everywhere" nor "constantly ask if there's > >> anything new" scales; what scales is actual pub/sub. In the case of > >> group IM, messages get pushed by some server (or some cluster of > >> entities acting as a logical server) to all and only those places > where > >> someone cares. There's some overhead in keeping track of where there > >> are places that someone cares, but in most use-cases I've seen it's > the > >> approach that scales the best. > > > >Do you have any references / links / copypasta / personal stories on > this kind of architecture research? I've been > >hungering for scalability research lately, and been surprised by much > of what I've read. I would assume polling with > >caching would be much faster than pub/sub because you can use much > dumber machinery, but I've also not investigated > >too many message queuing systems (I also don't work directly on IM). > I can't speak for others on this list, but if > >you cook up a scalability resource mail you've got an audience of at > least one ;) > > I will look around for some references; in my experience actual > practical stories about how stuff works get published far too rarely. :) > > My most recent experience with this is in some distributed computing > middleware (IBM WebSphere VE, nee XD). The exact situation there is > somewhat radically different, so the details of the solution we used > aren't really relevant, but the basic calculation is. > > If you have (say) a group with 1000 members, spread across 10 ADs, > where at a typical time 100 of those members are logged in, involving > 6 of the ADs, with a typical peak rate of 1 message every two seconds, > and you don't want to impose an additional latency of more than 5 > seconds, say (group IM with even just a 5-second delay would be > unusable imho, but we'll stick that in to get a lower bound), the > choices seem to be: > It's my understanding that 5 seconds group IM latency is routinely exceeded in practice. -- Tateru Nino http://www.massively.com/ From soft at lindenlab.com Wed Sep 10 09:21:31 2008 From: soft at lindenlab.com (Soft) Date: Wed Sep 10 09:21:34 2008 Subject: [sldev] Problem with script errors In-Reply-To: <48C7944C.1030602@streamsense.net> References: <48C7944C.1030602@streamsense.net> Message-ID: On Wed, Sep 10, 2008 at 4:33 AM, Thomas Grimshaw wrote: > I am posting this here since this jira outlines a potential exploit with the > way SL handles errors from scripts; I have only classified the Jira as a > "new feature" since it's not a bug as such.. should I upgrade it? > > ==== > > http://jira.secondlife.com/browse/SVC-3044 I've imported the two issues linked as children of SVC-3044 and created a separate issue for the error sender being a NULL_KEY. I'm not clear whether any change to the script error channel were intentional, but the LSL team should have an answer in quick order, which will determine how these are resolved. When you believe an issue should be framed as an exploit, please consider filing it in the SEC- category so we can roll out a fix before widespread misuse. As potential exploits go, this one is pretty minor but I still wanted to get that out there. With objects in SEC-, only you and Lindens can see the issue while it's being resolved. Once it's resolved, of course you'd be welcome to have the JIRA moved into SVC- or VWR- or talk about it for full disclosure. This is pretty similar to how most open source projects work. From chess at us.ibm.com Wed Sep 10 09:24:25 2008 From: chess at us.ibm.com (David M Chess) Date: Wed Sep 10 09:24:30 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: > From: "Dahlia Trimble" >I'm not sure of the relevance to this discussion, but I've often been >intrigued by some of the user numbers I see on IRC networks. Here's a quick >sample taken a moment ago from freenode: > >Total channels:5197 >Top 3 channels by *currently logged in* users: >#ubuntu 1362 >#gentoo 933 >#debian 819 > >What does this mean, other than freenode is dominated by geeks? It could >mean that they have solved some of the scalability problems with the IRC >model and it can serve as a reference. If I'm understanding what Zero said correctly, the problem with IRC scaling to SL levels wasn't the number of people concurrently logged into a group so much as it was the number of groups that each person was concurrently logged into. And I think that's a rather fundamental difference between the use-cases: I believe the average IRC user is only in a few channels at a time (heavy IRC users are invited to comment on that!), whereas in the SL model one is currently in like 25 at a time, and even when we fix things so that groups that don't need chat channels don't have them, we'll also be raising the 25-group limit, so I expect that 25-at-once will continue to be pretty typical. (And suggesting that SL residents just change their habits so that they *aren't* listening for anything that anyone might say in an of 25 group channels is a non-starter for me. Seems like a perfectly plausible way to use the system, it's the way that *I* want to use the system, and I don't want to say that the users have to change because we aren't smart enough to find a way to meet their expectations.) >I'd love to see an IRC client built into the viewer. Currently I can use a >web based irc client inside the viewer's browser window, but it takes far >more screen real estate than it needs. Then again, the communicate window >also takes far more screen real estate than it needs :( I hope that's slightly tongue-in-cheek. :) Or else people are going to start advocating for email / AIM / WoW clients built into the viewer, too, for the same reasons. :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/0b455374/attachment.htm From chess at us.ibm.com Wed Sep 10 09:24:25 2008 From: chess at us.ibm.com (David M Chess) Date: Wed Sep 10 09:24:31 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: > From: "Steven Harrison" > *waves to David* :) > I think that while pub/sub model does scale (I'm specifically thinking > of subscribers to an RSS feed, or something along the lines of > Twitter), is it a suitable architecture choice for group IM > conferencing? Wouldn't something more like IRC (as Dahlia mentions) be > more appropriate? However, I think that pub/sub could easily be done > with HTTP and RSS, but adding in some kind of IRC-esque functionality > would take a lot more work, I've probably been unclear here about what I mean by "pub/sub". In particular, subscribers to an RSS feed are *not* in fact subscribers in this sense; they are in fact polling, which is exactly what I want to avoid for scalability reasons. On the other hand, IRC basically is a pub/sub model: within the overlay network formed by the IRC servers, certain users (clients) subscribe to certain channels, and when a user talks ("publishes") on the channel, the message is sent (push-style) to all and only those servers that currently have a subscribed client. For me (and I think traditionally in comp sci before RSS terminology came along and muddied it up), pub/sub (publish/subscribe) refers to a system where there are topics or channels or subjects or whatever, some set of entities subscribe to one or more channels, and then some set of entities publishes one or more objects into one or more channels, and each subscriber is sent (rather than polling for) whatever objects are published into the channel(s) that that subscriber subscribes to. So the publisher does not (necessarily) know the list of entities that will get the message, and the subscribers do not (necessarily) know who the publishers will be; instead the association is via channels, and the pub/sub infrastructure takes care of it without the publishers or the subscribers having to do the accounting. Something like that anyway. :) Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/c4cd6dc1/attachment.htm From bill.hoffman at kitware.com Wed Sep 10 09:44:09 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Wed Sep 10 09:44:24 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <560CAC59-5D21-4488-A358-82F60D73A88F@ama-zing.co.uk> References: <48C532D5.3050300@kitware.com> <48C683B3.9010607@kitware.com> <48C6C973.6030306@kitware.com> <560CAC59-5D21-4488-A358-82F60D73A88F@ama-zing.co.uk> Message-ID: <48C7F959.2070403@kitware.com> Aimee Walton wrote: > On 9 Sep 2008, at 20:07, Bill Hoffman wrote: > >> Can you send me the CMakeCache.txt from both? >> >> Thanks. >> >> One thing I did notice is that the 2.6.2 one is using -gdwarf-2 for >> some reason... >> >> Also, what version of Xcode are you using? >> >> -Bill > > This is on Xcode 3.1 > > Aimee. > OK, wait, I am able to reproduce this with Xcode 3.0, and you are getting debug symbols... If you look at the build log you sent me you can see: ... setenv DEBUGGING_SYMBOLS YES setenv DEBUG_INFORMATION_FORMAT dwarf setenv GCC_GENERATE_DEBUGGING_SYMBOLS YES ... /Developer/usr/bin/gcc-4.0 -x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-pic -DCMAKE_INTDIR="Debug" -gdwarf-2 ... -gdwarf-2 is adding debug to the project, just not with -g. In the cmake 2.4.8 project, it has this: setenv DEBUGGING_SYMBOLS YES setenv DEBUG_INFORMATION_FORMAT dwarf setenv GCC_GENERATE_DEBUGGING_SYMBOLS NO setenv OTHER_CFLAGS "-Wall -Wno-sign-compare -Wno-trigraphs -Werror -mlong-branch -g " So, in 2.4.8 it was doing it the wrong way. It was adding -g to the cflags instead of using the native Xcode debugging approach. If I generate a project via the Xcode GUI, it works like the CMake 2.6.2 project, and uses -gdwarf-2 instead of -g. One of the other CMake developers said this: "I had a problem debugging stuff a couple weeks ago and had to uncheck the "Load symbols lazily" checkbox in the Xcode Debugging Preferences dialog." What makes you think it does not have debug symbols? -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoffman@kitware.com http://www.kitware.com 518-371-3971 (phone and fax) From dahliatrimble at gmail.com Wed Sep 10 10:47:22 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed Sep 10 10:47:28 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: On Wed, Sep 10, 2008 at 9:24 AM, David M Chess wrote: > > > From: "Dahlia Trimble" > > >I'm not sure of the relevance to this discussion, but I've often been > >intrigued by some of the user numbers I see on IRC networks. Here's a > quick > >sample taken a moment ago from freenode: > > > >Total channels:5197 > >Top 3 channels by *currently logged in* users: > >#ubuntu 1362 > >#gentoo 933 > >#debian 819 > > > >What does this mean, other than freenode is dominated by geeks? It could > >mean that they have solved some of the scalability problems with the IRC > >model and it can serve as a reference. > > > If I'm understanding what Zero said correctly, the problem with IRC scaling > to SL levels wasn't the number of people concurrently logged into a group so > much as it was the number of groups that each person was concurrently logged > into. And I think that's a rather fundamental difference between the > use-cases: I believe the average IRC user is only in a few channels at a > time (heavy IRC users are invited to comment on that!), whereas in the SL > model one is currently in like 25 at a time, and even when we fix things so > that groups that don't need chat channels don't have them, we'll also be > raising the 25-group limit, so I expect that 25-at-once will continue to be > pretty typical. I don't know if the IRC model is applicable to SL, but from my experience as a somewhat heavy IRC user, I just dont see any of the group chat problems that SL sees and I haven't seen any evidence that the SL *logged in* user and message volume is greater, if anything I would believe the IRC volume is much higher. >From what little I know of IRC architecture, each server can serve a limited amount of users and also forwards messages to other servers in a star configuration. I'm having a hard time envisioning a system that could scale better than that by just throwing hardware at it as seems possible with the IRC model. I imagine that each server could give a higher priority to forwarding messages to other servers if system loads were to peak. There may be other reasons why the IRC model is inadequate for SL type messaging, but I just can't find any evidence to support the scalability or volume arguments. > (And suggesting that SL residents just change their habits so that they > *aren't* listening for anything that anyone might say in an of 25 group > channels is a non-starter for me. Seems like a perfectly plausible way to > use the system, it's the way that *I* want to use the system, and I don't > want to say that the users have to change because we aren't smart enough to > find a way to meet their expectations.) I'm usually at my 25 group peak and I just don't see high message volumes, even though I am suscribed to several of the high-membership groups you listed earlier in the thread. > > > >I'd love to see an IRC client built into the viewer. Currently I can use a > >web based irc client inside the viewer's browser window, but it takes far > >more screen real estate than it needs. Then again, the communicate window > >also takes far more screen real estate than it needs :( > > > I hope that's slightly tongue-in-cheek. :) Or else people are going to > start advocating for email / AIM / WoW clients built into the viewer, too, > for the same reasons. :) > I wish it was tongue-in-cheek, but I am a heavy IRC user and so far it's the only way I can reliably communicate with others when SL's system fails, or if I want to message people on other grids. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/1a940afe/attachment-0001.htm From edward.artaud at gmail.com Wed Sep 10 11:20:59 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Wed Sep 10 11:21:03 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: Yes, that's why I why I addressed both in my previous email. The point is that single web servers (even with dynamic pages) routinely serve well over 20 requests a second (which I think was your estimate of # of requests for polling), and http already has ways to further optimized with etags and such, and more importantly, can be administered and scaled by a much less experienced ops team than a pub/sub system, whereas your approach will require the Lab to recruit very expensive MQ people out of IBM Global Services or Tibco to keep it reliably running 24/7. Most companies just don't have the resources and expertise to run large scale pub/sub systems. On Wed, Sep 10, 2008 at 9:24 AM, David M Chess wrote: > I've probably been unclear here about what I mean by "pub/sub". In > particular, subscribers to an RSS feed are *not* in fact subscribers in this > sense; they are in fact polling, which is exactly what I want to avoid for > scalability reasons. On the other hand, IRC basically is a pub/sub model: > within the overlay network formed by the IRC servers, certain users > (clients) subscribe to certain channels, and when a user talks ("publishes") > on the channel, the message is sent (push-style) to all and only those > servers that currently have a subscribed client. > > For me (and I think traditionally in comp sci before RSS terminology came > along and muddied it up), pub/sub (publish/subscribe) refers to a system > where there are topics or channels or subjects or whatever, some set of > entities subscribe to one or more channels, and then some set of entities > publishes one or more objects into one or more channels, and each subscriber > is sent (rather than polling for) whatever objects are published into the > channel(s) that that subscriber subscribes to. So the publisher does not > (necessarily) know the list of entities that will get the message, and the > subscribers do not (necessarily) know who the publishers will be; instead > the association is via channels, and the pub/sub infrastructure takes care > of it without the publishers or the subscribers having to do the accounting. > > Something like that anyway. :) > > Dale Innis > DaleInnisEmail@gmail.com > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From edward.artaud at gmail.com Wed Sep 10 11:40:25 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Wed Sep 10 11:40:29 2008 Subject: [sldev] Re: Viewer forks (was: SLDev Digest, Vol 21, Issue 25) In-Reply-To: References: <471283.16986.qm@web55605.mail.re4.yahoo.com> <5E4264B6-1444-4A0E-B69F-B8582E605875@ama-zing.co.uk> Message-ID: Yeah, the comparison to SLim is an unfortunate one that doesn't support your argument. Actually, both are symptoms of intentional or unintentional lack of transparency of roadmap. Prok's fears seam to stem from a belief that roadmap is unduly influenced by things Office Hours participation, which I don't have the experience to comment on one way or another although my inclination would be that the community creating alternate viewers to experiment with UI is a great idea. The SLim thing simply comes from the back that it's unclear to which degree busdev concerns are deltaing what has been previously communicated as direction. On Wed, Sep 10, 2008 at 5:24 AM, Argent Stonecutter wrote: > On 2008-09-09, at 22:28, Aimee Walton wrote: >> >> Following that logic we should all be extremely concerned and protesting >> the release of the SLim client, as it suggests that Linden Lab intend to >> remove the graphical world view from the standard viewer in favor of a text >> only client in future. > > Some of us ARE raising questions about the SLim client on technical grounds, > because it changes a lot of assumptions about IM and about LL's decision to > bypass XMPP, and about what it implies about the relationship of IM and SL > and Voice for the future. From liana at lindenlab.com Wed Sep 10 11:56:08 2008 From: liana at lindenlab.com (Liana Holmberg) Date: Wed Sep 10 11:56:10 2008 Subject: [sldev] Meet the Experts: CMake - reminder In-Reply-To: <48C0510D.9040404@lindenlab.com> References: <48C0510D.9040404@lindenlab.com> Message-ID: <48C81848.6060409@lindenlab.com> Reminder: We've invited Bill Hoffman to join us at tomorrow's office hour to talk about CMake. Note that we plan to use voice for this meeting. -L Liana Holmberg wrote: > And yet another event to announce -- > > Please join us for a "meet the experts" chat with Bill Hoffman of > Kitware, creators of CMake , and > Bryan O'Sullivan (Sardonyx Linden), leader of the CMake build system > implementation at Linden Lab. Format will be informal Q&A, so bring > your CMake questions. > > When: Open source office hour on11-Sept, 2pm PDT > Where: Hippotropolis Theater > > > This will be a voice-enabled event, and Bill and Bryan will be using > the spatial voice channel. > > Best, > Liana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/1b29d528/attachment.htm From gbrandon at gmail.com Wed Sep 10 12:14:54 2008 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed Sep 10 12:14:56 2008 Subject: [sldev] Valid uses for temporary image assets? Message-ID: I performed an experiment, uploading two textures using the same mechanism used for uploading bake (skin + clothing) textures. The experiment satisfied that the next day, I could no longer download the textures by opening the item in my inventory. I can't find any mention or documentation of how it works in the wiki, so I must ask: These temporary assets assumably are created in the millions every day when people upload their baked avatar textures. Would any other use of such temporary uploads be considered acceptable? Just for example, to put text on a prim for a short time? Are there limitations, technical or based in the TOS, that everyone should know about? Best wishes. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/fb2370f0/attachment.htm From lenglish5 at cox.net Wed Sep 10 13:00:24 2008 From: lenglish5 at cox.net (Lawson English) Date: Wed Sep 10 13:00:27 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <48C82758.9090903@cox.net> David M Chess wrote: > > > From: "Dahlia Trimble" > > [...] > >I'd love to see an IRC client built into the viewer. Currently I can > use a > >web based irc client inside the viewer's browser window, but it takes far > >more screen real estate than it needs. Then again, the communicate window > >also takes far more screen real estate than it needs :( > > I hope that's slightly tongue-in-cheek. :) Or else people are going > to start advocating for email / AIM / WoW clients built into the > viewer, too, for the same reasons. :) Actually, its the logical way to go for a universal client. Have any participating virtual world's viewer available in teh same app as the SL-compatible one (likewise with multiple chat clients). realXtend is going that route, for example, at least as far as the 3D viewer part is concerned. Lawson From me at signpostmarv.name Wed Sep 10 13:09:43 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed Sep 10 13:09:41 2008 Subject: [sldev] Valid uses for temporary image assets? In-Reply-To: References: Message-ID: <48C82987.9020409@signpostmarv.name> Brandon Lockaby wrote: > I can't find any mention or documentation of how it works in the wiki, > so I must ask: These temporary assets assumably are created in the > millions every day when people upload their baked avatar textures. > Would any other use of such temporary uploads be considered acceptable? Procedurally generated textures, web textures (not sure how OpenSim implements those, though there is a refresh parameter) ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080910/b5621c53/smime.bin From kelly at lindenlab.com Wed Sep 10 13:53:21 2008 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Sep 10 13:53:29 2008 Subject: [sldev] Valid uses for temporary image assets? In-Reply-To: References: Message-ID: <48C833C1.4070004@lindenlab.com> Brandon Lockaby wrote: > I performed an experiment, uploading two textures using the same > mechanism used for uploading bake (skin + clothing) textures. The > experiment satisfied that the next day, I could no longer download the > textures by opening the item in my inventory. > > I can't find any mention or documentation of how it works in the wiki, > so I must ask: These temporary assets assumably are created in the > millions every day when people upload their baked avatar textures. > Would any other use of such temporary uploads be considered > acceptable? Just for example, to put text on a prim for a short time? > Are there limitations, technical or based in the TOS, that everyone > should know about? > > Best wishes. I can offer technical details only. Temp textures are stored on the host of the region you are on when they are uploaded. When we store avatar texture data in the inventory db's we include a host url with the texture ID. This means that with this information (only exists on the back end) we can retrieve the baked textures for clothing even when you are on a different region. The inherent assumption with these textures is that they can be regenerated at any time if they aren't found. This assumption means we clean them up at whim without notifying any other process. I would highly recommend not using it. The textures there are cleaned via a chron job at unpredictable times for starters. I have some worries about performance implications as well. We really need better features for dynamic textures. From ravenglassrentals at yahoo.com Wed Sep 10 14:32:22 2008 From: ravenglassrentals at yahoo.com (Random Unsung) Date: Wed Sep 10 14:32:25 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 29 In-Reply-To: <20080910190108.64F01113BD6@stupor.lindenlab.com> Message-ID: <82367.16708.qm@web55601.mail.re4.yahoo.com> Edward, I don't suffer from "fears" and I am not riddled with "FUD" or a "Luddite". These are all absurd labels technologists put on people who question their activities in order to avoid real democratic participation -- which they claim to be offering. I raise objections simply to expose that these supposedly "open sourced" and "community" viewers and other features (like SLIM) aren't anything of the kind -- that in this case, Jacek has made a highly troubling and defiant "manifesto" in which he explicitly demands that "usable" viewers be created by deliberately going around the public's wishes. I don't think the Lindens should be endorsing such radicalism. Here you are illustrating again, Edward, that "thecommunity" isn't really the same thing as the genuine public interest; it's just a small technocratic lobbying group. When anyone from outside the "magic circle" tries to protest at the high-handedness, they are accused of "fears". My point isn't just that there isn't a transparent roadmap; it's that any group can come along and either buy its way into the viewer (Electric Sheep), with the Lindens copying some of the same features (the search all box) or lobbying through office hours for abstract visions not actually produced yet (Jacek) with a track record of removing "search" and L$ completely.? It doesn't matter if *those specific contest winners* are in fact put up again; the willingness to shed "search" and "$" vital to the economy and put in even more tangential or special-interest features -- under an agenda specifically to defy the average user -- are all developments of great concern. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080910/ce8c2fdf/attachment.htm From edward.artaud at gmail.com Wed Sep 10 15:52:53 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Wed Sep 10 15:53:11 2008 Subject: [sldev] Re: SLDev Digest, Vol 21, Issue 29 In-Reply-To: <82367.16708.qm@web55601.mail.re4.yahoo.com> References: <20080910190108.64F01113BD6@stupor.lindenlab.com> <82367.16708.qm@web55601.mail.re4.yahoo.com> Message-ID: Perhaps my choice of the word "fear" implied something I didn't intend, maybe objection is a less loaded term. However, I interpreted your objections to be based on your view that these features are going to be adopted into the viewer based solely on feedback or undue influence from minority interests that somehow have gained special leverage. As I said, I can't comment one way or another on that, although the points made by you and others about the CSI viewer, Dazzle, and certainly SLim indicate that there may very well be something to that. My point about transparency was that if we don't know what the roadmap for the viewer user interface is to begin with, then we really have no way of knowing exactly how or why it gets changed. If your objection is that it's inappropriate to give even the appearance of promotion or endorsement of third party viewer projects given the uncertainty that exists on the process that governs the official roadmap for the mainstream viewer, then that could very well be a legitimate concern. On Wed, Sep 10, 2008 at 2:32 PM, Random Unsung wrote: > Edward, I don't suffer from "fears" and I am not riddled with "FUD" or a > "Luddite". These are all absurd labels technologists put on people who > question their activities in order to avoid real democratic participation -- > which they claim to be offering. I raise objections simply to expose that > these supposedly "open sourced" and "community" viewers and other features > (like SLIM) aren't anything of the kind -- that in this case, Jacek has made > a highly troubling and defiant "manifesto" in which he explicitly demands > that "usable" viewers be created by deliberately going around the public's > wishes. I don't think the Lindens should be endorsing such radicalism. From Celierra at gmail.com Wed Sep 10 18:15:10 2008 From: Celierra at gmail.com (Celierra Darling) Date: Wed Sep 10 18:15:17 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: On Wed, Sep 10, 2008 at 12:24 PM, David M Chess wrote: > If I'm understanding what Zero said correctly, the problem with IRC scaling > to SL levels wasn't the number of people concurrently logged into a group so > much as it was the number of groups that each person was concurrently logged > into. And I think that's a rather fundamental difference between the > use-cases: I believe the average IRC user is only in a few channels at a > time (heavy IRC users are invited to comment on that!), whereas in the SL > model one is currently in like 25 at a time, and even when we fix things so > that groups that don't need chat channels don't have them, we'll also be > raising the 25-group limit, so I expect that 25-at-once will continue to be > pretty typical. > This seems to suggest running both systems, shifting the largest groups to IRC so they at least can have functional group chat (I think that's still broken, no?). And if IRC uses much fewer resources, one might also try using IRC for large rooms not quite near breakage, to save on resources, as long as it's not enough to start encountering this too-many-simultaneous-joins problem. But there are some obvious downsides, such as having to maintain both systems, and implementing a way to transition a room up to IRC (and down from IRC, too?). I'm not sure how the rewards and costs balance here. From robla at lindenlab.com Wed Sep 10 23:00:44 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Sep 10 23:00:51 2008 Subject: [sldev] [POLICY] sldev policy change Message-ID: <48C8B40C.6020901@lindenlab.com> Hi folks, I've made some changes to the main wiki page associated with this mailing list: http://wiki.secondlife.com/wiki/SLDev Most of it was cleanup and clarification, but there's a policy addition I'd like to point out: > * If someone else is violating mailing list policy, do not reply to > them on the list. Reply to them offlist if you feel you need to engage > them. If you feel disciplinary action is required, send mail to the > list administrator (). Engaging with > them on-list may result in the moderation bit being set on your account. If you have any comments on this, rather than replying on list, please put them here: http://wiki.secondlife.com/wiki/Talk:SLDev Thanks Rob From secret.argent at gmail.com Thu Sep 11 06:26:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 11 06:25:44 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48C7F366.3090504@weblogsinc.com> References: <48C7F366.3090504@weblogsinc.com> Message-ID: <64108BDF-BBF3-40FA-B91B-0CFD1B23A135@gmail.com> On 2008-09-10, at 11:18, Tateru Nino wrote: > It's my understanding that 5 seconds group IM latency is routinely > exceeded in practice. In fact when it's dropping messages it can take a couple of minutes for it to come back and tell you it can't send the message. From secret.argent at gmail.com Thu Sep 11 06:36:29 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 11 06:36:19 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: Message-ID: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> On 2008-09-10, at 11:24, David M Chess wrote: > (And suggesting that SL residents just change their habits so that > they *aren't* listening for anything that anyone might say in an of > 25 group channels is a non-starter for me. Seems like a perfectly > plausible way to use the system, it's the way that *I* want to use > the system, and I don't want to say that the users have to change > because we aren't smart enough to find a way to meet their > expectations.) I think the assumption that most people are in 25 groups is probably wrong. The only reason I'm in 25 groups is because I'm in land groups for vendors. I think the assumption that most groups people are in have active chat is probably wrong. None of those land groups have active chat. In a typical several-hour session, I will get chat from maybe three or four groups. For all but a couple of my groups I would prefer that there not be a group chat at all, because almost the only time there is traffic on the group is when a group notice goes out, and I immediately quit that group's chat. The only reason I keep listening for chat is because sometimes the group owner sends a notice in group chat instead of a notice. But while I would guess that maybe only a couple of percent of logged in residents would be in more than 3 or 4 active chat groups at once, we really need actual statistics from Linden Labs to see whose model is closer to reality. From chaosstar at gmail.com Thu Sep 11 06:38:31 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Sep 11 06:38:36 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909141007.771EC113B42@stupor.lindenlab.com> Message-ID: <9bb32d430809110638m33f5873eq39bbcccd1f53a878@mail.gmail.com> I don't see an issue there. There are zero problems with being logged into 25 IRC channels at one time. Even moreso, IRC channels have successfully held thousands of users at once without delay in comms, just as they have held 5 users. IRC servers are easily clustered into IRCnets, the technology is proven, stable, and with modern IRC servers and good settings, safe as well. I'm personally all in favor of trying the IRC protocol and server technology for SL group chats and conference IMs. On Thu, Sep 11, 2008 at 03:15, Celierra Darling wrote: > On Wed, Sep 10, 2008 at 12:24 PM, David M Chess wrote: >> If I'm understanding what Zero said correctly, the problem with IRC scaling >> to SL levels wasn't the number of people concurrently logged into a group so >> much as it was the number of groups that each person was concurrently logged >> into. And I think that's a rather fundamental difference between the >> use-cases: I believe the average IRC user is only in a few channels at a >> time (heavy IRC users are invited to comment on that!), whereas in the SL >> model one is currently in like 25 at a time, and even when we fix things so >> that groups that don't need chat channels don't have them, we'll also be >> raising the 25-group limit, so I expect that 25-at-once will continue to be >> pretty typical. From secret.argent at gmail.com Thu Sep 11 06:43:49 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 11 06:42:59 2008 Subject: [sldev] Valid uses for temporary image assets? In-Reply-To: <48C833C1.4070004@lindenlab.com> References: <48C833C1.4070004@lindenlab.com> Message-ID: <2267652F-F551-42F0-B8DB-E2B0894D8740@gmail.com> On 2008-09-10, at 15:53, Kelly Linden wrote: > We really need better features for dynamic textures. Nod. Things like text on a prim (whether simple text, SVG, or HTML) should be generated in the client, with only the actual text sent from the sim. From chaosstar at gmail.com Thu Sep 11 06:47:15 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Sep 11 06:47:19 2008 Subject: Fwd: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <9bb32d430809110645l3de6ed59w21cc12768c35bd74@mail.gmail.com> References: <20080909141007.771EC113B42@stupor.lindenlab.com> <9bb32d430809110638m33f5873eq39bbcccd1f53a878@mail.gmail.com> <9bb32d430809110645l3de6ed59w21cc12768c35bd74@mail.gmail.com> Message-ID: <9bb32d430809110647y22f83558o8a91defe359175fd@mail.gmail.com> SL's largest group has..around 2500-3k members right now. in orders for the IRC server having to serve all those people at once, they -all- need to be logged in at once at the given time. And most groups are way below that number. I don't see it as too much of an issue right now, but I'm all in favor of tests :3 On Thu, Sep 11, 2008 at 15:42, Ian Betteridge wrote: > I suspect that the issue may be that "thousands" isn't enough. In the > not-too-distant future, tens of thousands will be more like it. > > Not saying that IRC isn't a viable option as a model, but just that > because it works with thousands of users doesn't mean it will work > with what SL will need to deal with in the future. From chaosstar at gmail.com Thu Sep 11 06:48:21 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Sep 11 06:48:27 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <9bb32d430809110647y22f83558o8a91defe359175fd@mail.gmail.com> References: <20080909141007.771EC113B42@stupor.lindenlab.com> <9bb32d430809110638m33f5873eq39bbcccd1f53a878@mail.gmail.com> <9bb32d430809110645l3de6ed59w21cc12768c35bd74@mail.gmail.com> <9bb32d430809110647y22f83558o8a91defe359175fd@mail.gmail.com> Message-ID: <9bb32d430809110648k6fc3f22aw3b38378f1ef328a5@mail.gmail.com> Another advantage about using IRC for group chat and conferences that I see, by the way, is the fact that LL are trying to establish moderation tools for these, and IRC comes with a mature set of code and levels to do exactly that. From soft at lindenlab.com Thu Sep 11 07:19:05 2008 From: soft at lindenlab.com (Soft) Date: Thu Sep 11 07:19:08 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <9bb32d430809110648k6fc3f22aw3b38378f1ef328a5@mail.gmail.com> References: <20080909141007.771EC113B42@stupor.lindenlab.com> <9bb32d430809110638m33f5873eq39bbcccd1f53a878@mail.gmail.com> <9bb32d430809110645l3de6ed59w21cc12768c35bd74@mail.gmail.com> <9bb32d430809110647y22f83558o8a91defe359175fd@mail.gmail.com> <9bb32d430809110648k6fc3f22aw3b38378f1ef328a5@mail.gmail.com> Message-ID: On Thu, Sep 11, 2008 at 8:48 AM, Ambrosia wrote: > Another advantage about using IRC for group chat and conferences that > I see, by the way, is the fact that LL are trying to establish > moderation tools for these, and IRC comes with a mature set of code > and levels to do exactly that. Any of you could experiment with this without any kind of Linden involvement. It wouldn't be tough to create a channel name based on the group name, and an existing IRC network could be used for testing. At this point, a wiki design doc would be more productive than much of this thread. The IRC idea seems to make enough sense that someone at the Lab would likely jump on board if there were a promising prototype. Certainly, most of the Lindens you see on the sldev list would love to see another open protocol in use as well. From chess at us.ibm.com Thu Sep 11 07:41:47 2008 From: chess at us.ibm.com (David M Chess) Date: Thu Sep 11 07:42:21 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080909210039.E238A113A8E@stupor.lindenlab.com> Message-ID: >From: "Edward Artaud" > >There are a lot of tradeoffs of pub/sub vs polling, do a google seach >on the words 'pub sub polling' and you'll see many pages on the >subject. True pub/sub (as opposed to RESTful pub/sub aka polling) >means the server has to be statefully aware of who's subscribed. In >practice, not being statefully aware of your subscribers scales better >than being aware of them, and as Poppy points out, nice things like >caching and ETags/If-Modified-Since/304 Not Modified can be applied in >an much more fault tolerant and inexpensive brute force way rather >than true pub/sub which typically requires a lot more complex (and >harder to maintain systems) to operate at scale. Well, pub/sub requires that the system as a whole knows statefully who is subscribed. The publisher doesn't necessarily have to know, and no single server has to know, just the system as a whole; pub/sub can be done in various cleverly distributed ways to reduce the requirements on any one server. In my experience polling doesn't scale well unless there are relatively loose latency requirements (i.e. its okay if things sometimes take a long time to propogate), which I don't think we have in this case. Pub/sub doesn't have to be heavyweight and hard to maintain; again, I think IRC is basically pub/sub, and IRC implementations aren't afaik famously hard to maintain. >As to the user experience, there's no reason why any of the approaches discussed >would have to chage the existing user experience. I agree in general; on the other hand the user-experience requirements (like typically-short message delivery delays) can determine which approach is actually best. >My point is that >something I learned while implementing just such a system several >years ago was that group IM with no constraint on number of >participants is a totally different beast than 1 to 1 IM. I agree completely there. :) >I think what some people are forgetting in all these statistics and metrics >and whatever is that Large Groups in SL do not equal "Large number of people >in chat" > >A group may only be used to send notices out to the members, others people >drop chat as soon as they get the first message and do not "join back in" >until they feel like chatting. > >I have 25 groups, of those 25 groups only 5 of them EVER have chat occuring, >and of those 5 a very rarely keep all 5 going the entire time I am logged >in. That's entirely true; when we do the scaling calculations we have to look at what actually happens (and can be expected to happen) in detail, not just write down high-level numbers of groups and membership sizes and so on. I think we should assume that ultimately many people will belong to more than 25 groups, but (probably?) fewer than 25 that are used significantly for chat. And that the typical group chat channel will not be active with chatter 24/7 (although some probably will be). > From: Tateru Nino > It's my understanding that 5 seconds group IM latency is routinely > exceeded in practice. I would say "often" rather than "routinely". :) In the sense that when group chatlag gets that bad, the people in the channel perceive it as broken, and most of the traffic become people laughing or moaning about the lag. So my impression is that for the system to be perceived as *working*, typical latencies have to be far lower. > From: "Dahlia Trimble" >I don't know if the IRC model is applicable to SL, but from my experience as >a somewhat heavy IRC user, I just dont see any of the group chat problems >that SL sees and I haven't seen any evidence that the SL *logged in* user >and message volume is greater, if anything I would believe the IRC volume is >much higher. Do you have a rough feeling for how many different channels a user is likely to be in at once? Again, my impression from Zero is that the IRC provider(s) that he talked to cited that as a particular worry-point for scaling. >From what little I know of IRC architecture, each server can serve a limited >amount of users and also forwards messages to other servers in a star >configuration. I'm having a hard time envisioning a system that could scale >better than that by just throwing hardware at it as seems possible with the >IRC model. That's my impression also. Distributed pub/sub! (That is, there's no polling, and a message isn't sent to a server unless there's an interested user in that direction.) >I wish it was tongue-in-cheek, but I am a heavy IRC user and so far it's the >only way I can reliably communicate with others when SL's system fails, or >if I want to message people on other grids. Well, sure, but I don't really understand the desire for a normal IRC client _in the SL viewer_. Doesn't KDE / Gnome / Finder / Windows handle the problem of offering convenient access to both SL and IRC at the same time? > From: "Edward Artaud" >Yes, that's why I why I addressed both in my previous email. The >point is that single web servers (even with dynamic pages) routinely >serve well over 20 requests a second (which I think was your estimate >of # of requests for polling), and http already has ways to further >optimized with etags and such, That was 20 requests per second *per group*. Which I think would be a problem for the server, for nearby network bandwidth, etc. Etags don't help with the request rate, only the data volume. >and more importantly, can be >administered and scaled by a much less experienced ops team than a >pub/sub system, whereas your approach will require the Lab to recruit >very expensive MQ people out of IBM Global Services or Tibco to keep >it reliably running 24/7. Most companies just don't have the >resources and expertise to run large scale pub/sub systems. Pub/sub doesn't mean MQ or Tibco; it's a style of communication, not a product line. IRC uses pub/sub I believe, and I don't think IRC servers are all maintained via IBM service contracts. :) For that matter every mailman mailing list is using a pub/sub algorithm. > From: "Celierra Darling" >This seems to suggest running both systems, shifting the largest >groups to IRC so they at least can have functional group chat (I think >that's still broken, no?). And if IRC uses much fewer resources, one >might also try using IRC for large rooms not quite near breakage, to >save on resources, as long as it's not enough to start encountering >this too-many-simultaneous-joins problem. But there are some obvious >downsides, such as having to maintain both systems, and implementing a >way to transition a room up to IRC (and down from IRC, too?). I'm not >sure how the rewards and costs balance here. Ewww! :) Running two different systems at once would be rather a pain, as you say. It's a good point, though, that we should at least keep in mind the possibility of having more than just the two obvious kinds of groups (with IM and without IM). It's not impossible that a hybrid would be the best solution. A related question is whether the hybridization would be just at the implementation level (in which case we don't need any particular consensus on it, and people can play around), or whether the intragrid part of the protocol itself (the OGP for group IM) would need to have more than one style (which means we'd have to figure out the right standard to agree on). Thanks much to all for the comments, and as usual I will point at the Wiki for a good place to write stuff down: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080911/5bae004c/attachment-0001.htm From open at autistici.org Thu Sep 11 08:26:47 2008 From: open at autistici.org (Opensource Obscure) Date: Thu Sep 11 08:26:54 2008 Subject: [sldev] Question: Replacing current group chat with =?UTF-8?Q?XMPP=3F?= In-Reply-To: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> Message-ID: On Thu, 11 Sep 2008 08:36:29 -0500, Argent Stonecutter wrote: > On 2008-09-10, at 11:24, David M Chess wrote: >> (And suggesting that SL residents just change their habits so that >> they *aren't* listening for anything that anyone might say in an of >> 25 group channels is a non-starter for me. Seems like a perfectly >> plausible way to use the system, it's the way that *I* want to use >> the system, and I don't want to say that the users have to change >> because we aren't smart enough to find a way to meet their >> expectations.) > > I think the assumption that most people are in 25 groups is probably > wrong. The only reason I'm in 25 groups is because I'm in land groups > for vendors. Maybe Lindens could point us to existing stats about that, so that we can avoid to make assumptions? Personally, I'd be in 50 groups at least, if I could, and I'm not talking about land groups; I joined many groups that were related to my interests, "just to see what's going on" - or to receive updates about a project. I had to leave most of them in order to stay within the 25 groups limit. Actually, what I'm looking for when I join such a group is probably more similar to a newsletter / RSS feed than to a group conversation. That's often a one-way communication. I don't think I'm a typical SL user, but it appears to me that many other people are "passive" members in most of their groups. Like the land groups mentioned by Argent, many (most?) groups I'm in don't really have frequent, active chat. When people talk, it's usually the group admin speaking: otherwise, it's usually to go offtopic, or to spam. So I think that my SL experience would be better if I could join more groups, even if I couldn't actively participate in the chat - that way, I could probably even cope with a lower number of groups where I'm allowed to talk in the group chat. Opensource Obscure From robin.cornelius at gmail.com Thu Sep 11 09:06:57 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Sep 11 09:07:07 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> Message-ID: On Thu, Sep 11, 2008 at 4:26 PM, Opensource Obscure wrote: > I don't think I'm a typical SL user, but it appears to me that > many other people are "passive" members in most of their groups. > > Like the land groups mentioned by Argent, many (most?) groups > I'm in don't really have frequent, active chat. When people talk, > it's usually the group admin speaking: otherwise, it's usually > to go offtopic, or to spam. > > So I think that my SL experience would be better if I could > join more groups, even if I couldn't actively participate > in the chat - that way, I could probably even cope with a lower number > of groups where I'm allowed to talk in the group chat. Is there then a call to have a different type of group. One that does not have chat associated with it. It does seem to be very common to have "land groups" for basic management duties and the controlling of prims in vendor areas etc. Many of these groups don't need group chat and if these could be separate to the existing limited number of groups that might even be progress. But i can see a whole world of breakage there to implement that. Robin From edward.artaud at gmail.com Thu Sep 11 09:34:15 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Thu Sep 11 09:34:22 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909210039.E238A113A8E@stupor.lindenlab.com> Message-ID: It really depends on what the goals are. First of all, mailman is pub/sub in as much as there is distribution of mail to mailboxes, the mail typically gets from the mailbox to your client through some sort of poll mechanism. My suggestion is the same, except that it's a group mailbox (or feed) instead of individual mailboxes. Secondly, it's hard to argue that turning group chat into a feed system that gets polled for updates, even using long polling with keep-alive, is not going to be more fault-tolerant by virtue of it's simplicity than the current system, which is pub/sub. So, the tradeoff is more stable versus lower latency. IRC servers do go down and you can get disconnected from a channel, a feed polling architecture doesn't fail in that way, but yes, the latency issue is the question. Of course, with feed polling, you'd have other nice things, like potentially being able to subscribe to a group chat via RSS with a feed reader, and always having a recent group chat history if you joined a conversation late. Again, I'm coming at this from previous experienced being involved in a consumer group chat project, and the main complaints from users were that they found it unacceptable if they could not join the group chat room when they wanted to, had any sort of failure when trying to send a message, and getting kicked from a group chat due to the server they were connected to failing and missing chat history when they reconnected. Most users did not have an awareness of latency within the 5 second timeframe. I do think that IRC could be a viable option simply because of the maturity of it, but if you're proposing building a new non-irc chat system based on a pub/sub architecture and thinking that it's going to be more reliable that the current group chat implementation in SL, then all you're saying is you can do pub/sub better than the Lab, which I'm going to take with a grain of salt. For interoperability purposes, not originating a new architecture unless it is more simple and reliable than widely used open alternatives should be a key goal. On Thu, Sep 11, 2008 at 7:41 AM, David M Chess wrote: > Well, pub/sub requires that the system as a whole knows statefully who is > subscribed. The publisher doesn't necessarily have to know, and no single > server has to know, just the system as a whole; pub/sub can be done in > various cleverly distributed ways to reduce the requirements on any one > server. In my experience polling doesn't scale well unless there are > relatively loose latency requirements (i.e. its okay if things sometimes > take a long time to propogate), which I don't think we have in this case. > Pub/sub doesn't have to be heavyweight and hard to maintain; again, I think > IRC is basically pub/sub, and IRC implementations aren't afaik famously hard > to maintain. From chess at us.ibm.com Thu Sep 11 09:45:12 2008 From: chess at us.ibm.com (David M Chess) Date: Thu Sep 11 09:45:16 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080911144222.E70A841B3BF@stupor.lindenlab.com> Message-ID: Another set of agglomerated replies. :) From: Argent Stonecutter ... >On 2008-09-10, at 11:18, Tateru Nino wrote: >> It's my understanding that 5 seconds group IM latency is routinely >> exceeded in practice. > >In fact when it's dropping messages it can take a couple of minutes >for it to come back and tell you it can't send the message. Very true, but I take it that this is a problem we'd rather not reproduce, rather than something that we want to make sure that an intragrid Group IM system also does. :) (Although note that there's a difference between typical message-delivery latency and worst-case or typical-case time for failure detection; we should think of them both, with awareness of the difference.) >I think the assumption that most people are in 25 groups is probably >wrong. The only reason I'm in 25 groups is because I'm in land groups >for vendors. It would be interesting to see statistics on that. Given the number and volume of the voices I hear raised asking for the limit to be increased, I think it's pretty common for people to be in 25 groups, for whatever reason. Not necessarily 25 groups that really need a group chat channel, though. >I think the assumption that most groups people are in have active >chat is probably wrong. None of those land groups have active chat. I'm not assuming that most groups that people are in have active chat, either always or even ever. I'm guessing that if we (a) raise the 25-group limit, and (b) differentiate the groups that need a chat channel from those that don't, the result will be that people belong to more chat-using groups than they do now, but likely not as many as 25. >In a typical several-hour session, I will get chat from maybe three >or four groups. For all but a couple of my groups I would prefer that >there not be a group chat at all, because almost the only time there >is traffic on the group is when a group notice goes out, and I >immediately quit that group's chat. The only reason I keep listening >for chat is because sometimes the group owner sends a notice in group >chat instead of a notice. Yep, again I think it will be very useful to, if we can, find out more about current group-chat behavior than we already know. I pretty much never quit group chats myself; I might miss something interesting! And yes, that means that I'm constantly scrolling my group-chat window left and right to see all the tabs, and I hate that. :) > But while I would guess that maybe only a couple of percent of logged > in residents would be in more than 3 or 4 active chat groups at once, > we really need actual statistics from Linden Labs to see whose model > is closer to reality. Agreed. And we also need to differentiate between "active chat groups" in the sense of "chat going on right now", and "active chat groups" in the sense of "have a chat channel that is used reasonably often, even if not necessarily right now". When we do scaling analysis, we'll need both numbers. (For instance, if you're polling it's the latter number that matters most, whereas if you're pushing the former is generally more important.) From: Ambrosia >I don't see an issue there. There are zero problems with being logged >into 25 IRC channels at one time. Ah, good data! I went back to look at the office hours in question ( https://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_September_04 ), and it looks like I've been mistaken (blush). Zero was talking about XMPP, not IRC. Ooops! :) We should drag Zero and Zha into this, and see if they're aware of any suspected limitations in IRC. From: Soft >At this point, a wiki design doc would be more productive than much of >this thread. There is a strawman design at " https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#A_Simple_Design_Example ". /me begs for comments and contributions there (or elsewhere, with a link from there) yet again. Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080911/08ae89bd/attachment.htm From bill.hoffman at kitware.com Thu Sep 11 13:06:17 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu Sep 11 13:06:29 2008 Subject: [sldev] CMake 2.6.2 RC 3 In-Reply-To: <48C7F959.2070403@kitware.com> References: <48C532D5.3050300@kitware.com> <48C683B3.9010607@kitware.com> <48C6C973.6030306@kitware.com> <560CAC59-5D21-4488-A358-82F60D73A88F@ama-zing.co.uk> <48C7F959.2070403@kitware.com> Message-ID: <48C97A39.6020300@kitware.com> Found it! I have reproduced the problem and created a fix! Thanks for the bug report. I will have a new RC to try very soon. -Bill From dahliatrimble at gmail.com Thu Sep 11 13:32:45 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Sep 11 13:32:48 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909210039.E238A113A8E@stupor.lindenlab.com> Message-ID: On Thu, Sep 11, 2008 at 7:41 AM, David M Chess wrote: > > > > From: "Dahlia Trimble" > > >I don't know if the IRC model is applicable to SL, but from my experience > as > >a somewhat heavy IRC user, I just dont see any of the group chat problems > >that SL sees and I haven't seen any evidence that the SL *logged in* user > >and message volume is greater, if anything I would believe the IRC volume > is > >much higher. > > Do you have a rough feeling for how many different channels a user is > likely to be in at once? Again, my impression from Zero is that the IRC > provider(s) that he talked to cited that as a particular worry-point for > scaling. No, I don't have a feel for this yer, and I don't have any data about how multiple channel usage affects current IRC servers. I suspect these data may be fairly easy to get as most servers will tell you what other channels any user is currently logged into, and the source code could be studied to offer some suggestions about what limitations there may be, or how they could be overcome if they do exist. There are also several available open source implementations of servers, and some may perform better or worse in this regard. > >From what little I know of IRC architecture, each server can serve a > limited > >amount of users and also forwards messages to other servers in a star > >configuration. I'm having a hard time envisioning a system that could > scale > >better than that by just throwing hardware at it as seems possible with > the > >IRC model. > > That's my impression also. Distributed pub/sub! (That is, there's no > polling, and a message isn't sent to a server unless there's an interested > user in that direction.) > > >I wish it was tongue-in-cheek, but I am a heavy IRC user and so far it's > the > >only way I can reliably communicate with others when SL's system fails, or > >if I want to message people on other grids. > > Well, sure, but I don't really understand the desire for a normal IRC > client _in the SL viewer_. Doesn't KDE / Gnome / Finder / Windows handle > the problem of offering convenient access to both SL and IRC at the same > time? It's a matter of how screen real estate is used. It's easy to forget that end users are using SL because it offers a 3D immersive experience, and without that, it's just yet another chat client. Also I will most likely be using SL on a laptop and screen real estate is critical, having yet another window simultaneously appearing on the screen severely reduces the 3D experience. I haven't seen many chat clients of any kind that take this into regard, and unfortunately that includes the Communicate window and the minimum size that it will size to, although it has improved from previous prototypes. Using the chat window in another application and minimizing it or letting it move behind the SL client window effectively removes me from the conversation, so that isn't the best option. A possible compromise would be some kind of client-side plug in architecture for chat protocols, or even a chat redirection proxy if the client can't be modified in this sense. Then again a well designed AJAX web chat client running in a browser window inside the SL client may even be a contender to replace the Communicate window. Here's how I use IRC in the current SL viewers: 1. press the F1 key to open a help browser 2. type "google.com" in the URL field and hit 3. search for "web irc" 4. pick one, some offer connections to different networks and some may use more or less screen area than others. 5. sign in. resize the browser window as appropriate and chat away while you are using SL. Note that if you close the browser of navigate to another page, you will most likely need to relog into the web chat client to reuse it, as there doesnt seem to be multiple tabs available in the client's browser. Also, I'm not trying to advocate a switch to IRC, but rather I'm suggesting it as a possible alternative and as a well-oiled machine worthy of study. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080911/1d0fe11a/attachment.htm From soft at lindenlab.com Thu Sep 11 14:05:44 2008 From: soft at lindenlab.com (Soft) Date: Thu Sep 11 14:05:47 2008 Subject: [sldev] Bill Hoffman (cmake) in-world now Message-ID: A reminder -- Bill Hoffman is in-world speaking about cmake, starting right now: http://slurl.com/secondlife/Hippotropolis/239/8/27 From labrat.hb at gmail.com Thu Sep 11 15:04:21 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Sep 11 15:04:29 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909210039.E238A113A8E@stupor.lindenlab.com> Message-ID: This page may be of some use: http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols And from the comparison provided there it would seem that PSYC - http://www.psyced.org/ or http://about.psyc.eu/ would be a very good choice for the back end system. Note that the psyced server provides IRC as well as XMPP. On Thu, Sep 11, 2008 at 1:32 PM, Dahlia Trimble wrote: > > > On Thu, Sep 11, 2008 at 7:41 AM, David M Chess wrote: > >> >> >> > From: "Dahlia Trimble" >> >> >I don't know if the IRC model is applicable to SL, but from my experience >> as >> >a somewhat heavy IRC user, I just dont see any of the group chat problems >> >that SL sees and I haven't seen any evidence that the SL *logged in* user >> >and message volume is greater, if anything I would believe the IRC volume >> is >> >much higher. >> >> Do you have a rough feeling for how many different channels a user is >> likely to be in at once? Again, my impression from Zero is that the IRC >> provider(s) that he talked to cited that as a particular worry-point for >> scaling. > > > No, I don't have a feel for this yer, and I don't have any data about how > multiple channel usage affects current IRC servers. I suspect these data may > be fairly easy to get as most servers will tell you what other channels any > user is currently logged into, and the source code could be studied to offer > some suggestions about what limitations there may be, or how they could be > overcome if they do exist. There are also several available open source > implementations of servers, and some may perform better or worse in this > regard. > > >> >From what little I know of IRC architecture, each server can serve a >> limited >> >amount of users and also forwards messages to other servers in a star >> >configuration. I'm having a hard time envisioning a system that could >> scale >> >better than that by just throwing hardware at it as seems possible with >> the >> >IRC model. >> >> That's my impression also. Distributed pub/sub! (That is, there's no >> polling, and a message isn't sent to a server unless there's an interested >> user in that direction.) >> >> >I wish it was tongue-in-cheek, but I am a heavy IRC user and so far it's >> the >> >only way I can reliably communicate with others when SL's system fails, >> or >> >if I want to message people on other grids. >> >> Well, sure, but I don't really understand the desire for a normal IRC >> client _in the SL viewer_. Doesn't KDE / Gnome / Finder / Windows handle >> the problem of offering convenient access to both SL and IRC at the same >> time? > > > It's a matter of how screen real estate is used. It's easy to forget that > end users are using SL because it offers a 3D immersive experience, and > without that, it's just yet another chat client. Also I will most likely be > using SL on a laptop and screen real estate is critical, having yet another > window simultaneously appearing on the screen severely reduces the 3D > experience. I haven't seen many chat clients of any kind that take this into > regard, and unfortunately that includes the Communicate window and the > minimum size that it will size to, although it has improved from previous > prototypes. Using the chat window in another application and minimizing it > or letting it move behind the SL client window effectively removes me from > the conversation, so that isn't the best option. A possible compromise would > be some kind of client-side plug in architecture for chat protocols, or even > a chat redirection proxy if the client can't be modified in this sense. Then > again a well designed AJAX web chat client running in a browser window > inside the SL client may even be a contender to replace the Communicate > window. > > Here's how I use IRC in the current SL viewers: > 1. press the F1 key to open a help browser > 2. type "google.com" in the URL field and hit > 3. search for "web irc" > 4. pick one, some offer connections to different networks and some may use > more or less screen area than others. > 5. sign in. resize the browser window as appropriate and chat away while > you are using SL. > > Note that if you close the browser of navigate to another page, you will > most likely need to relog into the web chat client to reuse it, as there > doesnt seem to be multiple tabs available in the client's browser. > > > Also, I'm not trying to advocate a switch to IRC, but rather I'm suggesting > it as a possible alternative and as a well-oiled machine worthy of study. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080911/316dd24f/attachment-0001.htm From robla at lindenlab.com Thu Sep 11 18:40:16 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Sep 11 18:40:21 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080909210039.E238A113A8E@stupor.lindenlab.com> Message-ID: <48C9C880.6060004@lindenlab.com> Hi all, This thread has gone on a really, really long time. There is already a feature request filed for this, that seems like a better place to discuss: https://jira.secondlife.com/browse/SVC-419 Additionally, a wiki page describing the options (IRC, XMPP, etc) with the pros and cons, would also be a very productive exercise. The reason Linden Lab isn't really participating in this discussion is that it's not something we're working on right now. Someone else *could* implement an XMPP gateway using what's available today, or for that matter could implement a libpurple library that implements the Second Life chat protocol. However, what's a little frustrating about this conversation is that I don't think any of the parties here are seriously discussing doing this themselves. If you're looking to build the case that Linden Lab should do this, the best place to do it is by constructing a solidly documented case on wiki.secondlife.com, and linking to it from that JIRA feature above, and getting a ton of votes on it. Not only will that be the most expedient method, but even if it doesn't work for now, there's something documented for the next time this comes up. A mailing list discussion alone isn't going to be convincing, so please, pitch in elsewhere rather than continuing to weigh in on this thread. Thanks Rob On 9/11/08 3:04 PM, Harold Brown wrote: > This page may be of some use: > > http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols > > And from the comparison provided there it would seem that > > PSYC - http://www.psyced.org/ or http://about.psyc.eu/ > > would be a very good choice for the back end system. Note that the > psyced server provides IRC as well as XMPP. > > > On Thu, Sep 11, 2008 at 1:32 PM, Dahlia Trimble > > wrote: > > > > On Thu, Sep 11, 2008 at 7:41 AM, David M Chess > wrote: > > > > > From: "Dahlia Trimble" > > > >I don't know if the IRC model is applicable to SL, but from > my experience as > >a somewhat heavy IRC user, I just dont see any of the group > chat problems > >that SL sees and I haven't seen any evidence that the SL > *logged in* user > >and message volume is greater, if anything I would believe > the IRC volume is > >much higher. > > Do you have a rough feeling for how many different channels a > user is likely to be in at once? Again, my impression from > Zero is that the IRC provider(s) that he talked to cited that > as a particular worry-point for scaling. > > > No, I don't have a feel for this yer, and I don't have any data > about how multiple channel usage affects current IRC servers. I > suspect these data may be fairly easy to get as most servers will > tell you what other channels any user is currently logged into, > and the source code could be studied to offer some suggestions > about what limitations there may be, or how they could be overcome > if they do exist. There are also several available open source > implementations of servers, and some may perform better or worse > in this regard. > > > >From what little I know of IRC architecture, each server can > serve a limited > >amount of users and also forwards messages to other servers > in a star > >configuration. I'm having a hard time envisioning a system > that could scale > >better than that by just throwing hardware at it as seems > possible with the > >IRC model. > > That's my impression also. Distributed pub/sub! (That is, > there's no polling, and a message isn't sent to a server > unless there's an interested user in that direction.) > > >I wish it was tongue-in-cheek, but I am a heavy IRC user and > so far it's the > >only way I can reliably communicate with others when SL's > system fails, or > >if I want to message people on other grids. > > Well, sure, but I don't really understand the desire for a > normal IRC client _in the SL viewer_. Doesn't KDE / Gnome / > Finder / Windows handle the problem of offering convenient > access to both SL and IRC at the same time? > > > It's a matter of how screen real estate is used. It's easy to > forget that end users are using SL because it offers a 3D > immersive experience, and without that, it's just yet another chat > client. Also I will most likely be using SL on a laptop and screen > real estate is critical, having yet another window simultaneously > appearing on the screen severely reduces the 3D experience. I > haven't seen many chat clients of any kind that take this into > regard, and unfortunately that includes the Communicate window and > the minimum size that it will size to, although it has improved > from previous prototypes. Using the chat window in another > application and minimizing it or letting it move behind the SL > client window effectively removes me from the conversation, so > that isn't the best option. A possible compromise would be some > kind of client-side plug in architecture for chat protocols, or > even a chat redirection proxy if the client can't be modified in > this sense. Then again a well designed AJAX web chat client > running in a browser window inside the SL client may even be a > contender to replace the Communicate window. > > Here's how I use IRC in the current SL viewers: > 1. press the F1 key to open a help browser > 2. type "google.com " in the URL field and hit > > 3. search for "web irc" > 4. pick one, some offer connections to different networks and some > may use more or less screen area than others. > 5. sign in. resize the browser window as appropriate and chat away > while you are using SL. > > Note that if you close the browser of navigate to another page, > you will most likely need to relog into the web chat client to > reuse it, as there doesnt seem to be multiple tabs available in > the client's browser. > > > Also, I'm not trying to advocate a switch to IRC, but rather I'm > suggesting it as a possible alternative and as a well-oiled > machine worthy of study. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From secret.argent at gmail.com Thu Sep 11 22:11:02 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 11 22:10:10 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> Message-ID: <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> On 2008-09-11, at 11:06, Robin Cornelius wrote: > Is there then a call to have a different type of group. One that does > not have chat associated with it. That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . An alternative would be to allow you to have an association with a group that doesn't include chat or any of the other high-impact features. There are a number of groups that I would like to "suspend membership" in without having to re-apply to rejoin. See http://jira.secondlife.com/browse/SVC-1173 . On 2008-09-11, at 11:45, David M Chess wrote: > I take it that this is a problem we'd rather not reproduce, rather > than something that we want to make sure that an intragrid Group IM > system also does. :) It's just an indication that fairly high latency for starting a group conversation isn't automatically a fatal flaw. Certainly 10-20 seconds latency is entirely acceptable. > Given the number and volume of the voices I hear raised asking for > the limit to be increased, I think it's pretty common for people to > be in 25 groups, for whatever reason. Not necessarily 25 groups > that really need a group chat channel, though. That would be the point there. I'd also like to note that person-person IM and group IM are generally different kinds of conversation, have different goals, anddon't need to share transport. For example, I could EASILY see logging in to IRC to get into a group chat without wanting to get into point-to-point chat with individuals, and vice versa. Also, it would be nice to be able to log in to office hours with a client that doesn't require a wide open firewall. Using open protocols for IM and group IM would allow me to run (for example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed into. I can't see that happening with any likely Vivox-based client. From labrat.hb at gmail.com Fri Sep 12 10:00:07 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Sep 12 10:00:12 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: lynX a developer of PSYC has just recently downloaded the OpenSIM svn and had expressed interest (yesterday) of integrating PSYC with it (totally unrelated to the conversation here) I mentioned the discussion here and they posted the following on their wiki: http://about.psyc.eu/Second_Life On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter < secret.argent@gmail.com> wrote: > On 2008-09-11, at 11:06, Robin Cornelius wrote: > >> Is there then a call to have a different type of group. One that does >> not have chat associated with it. >> > > That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . > > An alternative would be to allow you to have an association with a group > that doesn't include chat or any of the other high-impact features. There > are a number of groups that I would like to "suspend membership" in without > having to re-apply to rejoin. > > See http://jira.secondlife.com/browse/SVC-1173 . > > On 2008-09-11, at 11:45, David M Chess wrote: > >> I take it that this is a problem we'd rather not reproduce, rather than >> something that we want to make sure that an intragrid Group IM system also >> does. :) >> > > It's just an indication that fairly high latency for starting a group > conversation isn't automatically a fatal flaw. Certainly 10-20 seconds > latency is entirely acceptable. > > Given the number and volume of the voices I hear raised asking for the >> limit to be increased, I think it's pretty common for people to be in 25 >> groups, for whatever reason. Not necessarily 25 groups that really need a >> group chat channel, though. >> > > That would be the point there. > > I'd also like to note that person-person IM and group IM are generally > different kinds of conversation, have different goals, anddon't need to > share transport. For example, I could EASILY see logging in to IRC to get > into a group chat without wanting to get into point-to-point chat with > individuals, and vice versa. > > Also, it would be nice to be able to log in to office hours with a client > that doesn't require a wide open firewall. > > Using open protocols for IM and group IM would allow me to run (for > example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed > into. I can't see that happening with any likely Vivox-based client. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/e9b1e0b4/attachment.htm From dahliatrimble at gmail.com Fri Sep 12 10:40:30 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Sep 12 10:40:34 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: PSYC looks interesting but I can't seem to find any licensing terms on any of their web sites. Also looks like they haven't had much opportunity to do any really large scale testing of their protocol. Anyway if they are interested in working with Opensim then this thread should probably be continued on the opensim-dev mailing list. Details of the list can be found at https://lists.berlios.de/mailman/listinfo/opensim-dev On Fri, Sep 12, 2008 at 10:00 AM, Harold Brown wrote: > lynX a developer of PSYC has just recently downloaded the OpenSIM svn and > had expressed interest (yesterday) of integrating PSYC with it (totally > unrelated to the conversation here) I mentioned the discussion here and they > posted the following on their wiki: > > http://about.psyc.eu/Second_Life > > > > > On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter < > secret.argent@gmail.com> wrote: > >> On 2008-09-11, at 11:06, Robin Cornelius wrote: >> >>> Is there then a call to have a different type of group. One that does >>> not have chat associated with it. >>> >> >> That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . >> >> An alternative would be to allow you to have an association with a group >> that doesn't include chat or any of the other high-impact features. There >> are a number of groups that I would like to "suspend membership" in without >> having to re-apply to rejoin. >> >> See http://jira.secondlife.com/browse/SVC-1173 . >> >> On 2008-09-11, at 11:45, David M Chess wrote: >> >>> I take it that this is a problem we'd rather not reproduce, rather than >>> something that we want to make sure that an intragrid Group IM system also >>> does. :) >>> >> >> It's just an indication that fairly high latency for starting a group >> conversation isn't automatically a fatal flaw. Certainly 10-20 seconds >> latency is entirely acceptable. >> >> Given the number and volume of the voices I hear raised asking for the >>> limit to be increased, I think it's pretty common for people to be in 25 >>> groups, for whatever reason. Not necessarily 25 groups that really need a >>> group chat channel, though. >>> >> >> That would be the point there. >> >> I'd also like to note that person-person IM and group IM are generally >> different kinds of conversation, have different goals, anddon't need to >> share transport. For example, I could EASILY see logging in to IRC to get >> into a group chat without wanting to get into point-to-point chat with >> individuals, and vice versa. >> >> Also, it would be nice to be able to log in to office hours with a client >> that doesn't require a wide open firewall. >> >> Using open protocols for IM and group IM would allow me to run (for >> example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed >> into. I can't see that happening with any likely Vivox-based client. >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/1a76e38e/attachment-0001.htm From labrat.hb at gmail.com Fri Sep 12 10:49:19 2008 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Sep 12 10:49:24 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: GPL version 2 http://www.psyced.org/dist/LICENSE.txt On Fri, Sep 12, 2008 at 10:40 AM, Dahlia Trimble wrote: > PSYC looks interesting but I can't seem to find any licensing terms on any > of their web sites. Also looks like they haven't had much opportunity to do > any really large scale testing of their protocol. Anyway if they are > interested in working with Opensim then this thread should probably be > continued on the opensim-dev mailing list. Details of the list can be found > at https://lists.berlios.de/mailman/listinfo/opensim-dev > > > On Fri, Sep 12, 2008 at 10:00 AM, Harold Brown wrote: > >> lynX a developer of PSYC has just recently downloaded the OpenSIM svn and >> had expressed interest (yesterday) of integrating PSYC with it (totally >> unrelated to the conversation here) I mentioned the discussion here and they >> posted the following on their wiki: >> >> http://about.psyc.eu/Second_Life >> >> >> >> >> On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter < >> secret.argent@gmail.com> wrote: >> >>> On 2008-09-11, at 11:06, Robin Cornelius wrote: >>> >>>> Is there then a call to have a different type of group. One that does >>>> not have chat associated with it. >>>> >>> >>> That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . >>> >>> An alternative would be to allow you to have an association with a group >>> that doesn't include chat or any of the other high-impact features. There >>> are a number of groups that I would like to "suspend membership" in without >>> having to re-apply to rejoin. >>> >>> See http://jira.secondlife.com/browse/SVC-1173 . >>> >>> On 2008-09-11, at 11:45, David M Chess wrote: >>> >>>> I take it that this is a problem we'd rather not reproduce, rather than >>>> something that we want to make sure that an intragrid Group IM system also >>>> does. :) >>>> >>> >>> It's just an indication that fairly high latency for starting a group >>> conversation isn't automatically a fatal flaw. Certainly 10-20 seconds >>> latency is entirely acceptable. >>> >>> Given the number and volume of the voices I hear raised asking for the >>>> limit to be increased, I think it's pretty common for people to be in 25 >>>> groups, for whatever reason. Not necessarily 25 groups that really need a >>>> group chat channel, though. >>>> >>> >>> That would be the point there. >>> >>> I'd also like to note that person-person IM and group IM are generally >>> different kinds of conversation, have different goals, anddon't need to >>> share transport. For example, I could EASILY see logging in to IRC to get >>> into a group chat without wanting to get into point-to-point chat with >>> individuals, and vice versa. >>> >>> Also, it would be nice to be able to log in to office hours with a client >>> that doesn't require a wide open firewall. >>> >>> Using open protocols for IM and group IM would allow me to run (for >>> example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed >>> into. I can't see that happening with any likely Vivox-based client. >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/12eb18c2/attachment.htm From dahliatrimble at gmail.com Fri Sep 12 10:55:09 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Sep 12 10:55:34 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: That wouldn't be acceptable for inclusion into Opensim then as it's incompatible with the BSD license that Opensim uses. On Fri, Sep 12, 2008 at 10:49 AM, Harold Brown wrote: > GPL version 2 > http://www.psyced.org/dist/LICENSE.txt > > > > On Fri, Sep 12, 2008 at 10:40 AM, Dahlia Trimble wrote: > >> PSYC looks interesting but I can't seem to find any licensing terms on any >> of their web sites. Also looks like they haven't had much opportunity to do >> any really large scale testing of their protocol. Anyway if they are >> interested in working with Opensim then this thread should probably be >> continued on the opensim-dev mailing list. Details of the list can be found >> at https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> On Fri, Sep 12, 2008 at 10:00 AM, Harold Brown wrote: >> >>> lynX a developer of PSYC has just recently downloaded the OpenSIM svn and >>> had expressed interest (yesterday) of integrating PSYC with it (totally >>> unrelated to the conversation here) I mentioned the discussion here and they >>> posted the following on their wiki: >>> >>> http://about.psyc.eu/Second_Life >>> >>> >>> >>> >>> On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter < >>> secret.argent@gmail.com> wrote: >>> >>>> On 2008-09-11, at 11:06, Robin Cornelius wrote: >>>> >>>>> Is there then a call to have a different type of group. One that does >>>>> not have chat associated with it. >>>>> >>>> >>>> That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . >>>> >>>> An alternative would be to allow you to have an association with a group >>>> that doesn't include chat or any of the other high-impact features. There >>>> are a number of groups that I would like to "suspend membership" in without >>>> having to re-apply to rejoin. >>>> >>>> See http://jira.secondlife.com/browse/SVC-1173 . >>>> >>>> On 2008-09-11, at 11:45, David M Chess wrote: >>>> >>>>> I take it that this is a problem we'd rather not reproduce, rather than >>>>> something that we want to make sure that an intragrid Group IM system also >>>>> does. :) >>>>> >>>> >>>> It's just an indication that fairly high latency for starting a group >>>> conversation isn't automatically a fatal flaw. Certainly 10-20 seconds >>>> latency is entirely acceptable. >>>> >>>> Given the number and volume of the voices I hear raised asking for the >>>>> limit to be increased, I think it's pretty common for people to be in 25 >>>>> groups, for whatever reason. Not necessarily 25 groups that really need a >>>>> group chat channel, though. >>>>> >>>> >>>> That would be the point there. >>>> >>>> I'd also like to note that person-person IM and group IM are generally >>>> different kinds of conversation, have different goals, anddon't need to >>>> share transport. For example, I could EASILY see logging in to IRC to get >>>> into a group chat without wanting to get into point-to-point chat with >>>> individuals, and vice versa. >>>> >>>> Also, it would be nice to be able to log in to office hours with a >>>> client that doesn't require a wide open firewall. >>>> >>>> Using open protocols for IM and group IM would allow me to run (for >>>> example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed >>>> into. I can't see that happening with any likely Vivox-based client. >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/dc2ffe99/attachment.htm From bill.hoffman at kitware.com Fri Sep 12 11:46:57 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Sep 12 11:47:09 2008 Subject: [sldev] CMake 2.6.2 RC 4 is ready Message-ID: <48CAB921.2070402@kitware.com> Please try 2.6.2 RC 4 from here: http://www.cmake.org/files/v2.6/?C=M;O=D This should fix the Mac debug problem reported with RC 3. Thanks. -Bill From me at signpostmarv.name Fri Sep 12 12:46:02 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Fri Sep 12 12:46:10 2008 Subject: [sldev] source code sherpa wanted [was checking how the viewer gets Event info] Message-ID: <48CAC6FA.2070900@signpostmarv.name> copied from http://blog.signpostmarv.name/2008/09/10/source-code-sherpa-wanted/ > I?m in need of a source code sherpa to help me navigate the SL Viewer > source code- specifically the portions involved in the retrieval of > the in-world events data, so that I can have a more reliable, single > data source for the events portion of sw.slr. > > If you?re interested in helping out, send me an IM in-world, or on Skype. > ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080912/560ba463/smime.bin From chess at us.ibm.com Fri Sep 12 12:50:53 2008 From: chess at us.ibm.com (David M Chess) Date: Fri Sep 12 12:50:56 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <20080912174034.A6156113CB4@stupor.lindenlab.com> Message-ID: > From: Rob Lanphier > This thread has gone on a really, really long time. There is already a > feature request filed for this, that seems like a better place to discuss: > https://jira.secondlife.com/browse/SVC-419 This is really a convergence of two topics, I think: one about improving the current SL group IM (which might well be best in the JIRA), and another about what needs to be in OGP to support inter-grid group IM, regardless of what SL uses to implement it. Is there a better list than sldev for the latter purpose? Or we could start beginning the subject lines with [OGP] or something to warn people off. :) > Additionally, a wiki page describing the options (IRC, XMPP, etc) with > the pros and cons, would also be a very productive exercise. As required by Federal law :) I point at: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#A_Simple_Design_Example and the rest of that page as well, and beg for contributions. > However, what's a little frustrating about this conversation is that I > don't think any of the parties here are seriously discussing doing this > themselves. I think it's reasonable to talk about requirements and desired features and all even if one isn't planning to start writing code right away? :) Although this might not be the right venue for that discussion. For what it's worth, at some of the recent interop-related meetings, it's been suggested that the next POC that we tackle (after raw AV TP and before the complexities of assets) might be intergrid IM; that's why I started the Wiki page in the first place. So there are at least some coders with itchy fingers! > A mailing list discussion alone isn't going to be convincing, so please, > pitch in elsewhere rather than continuing to weigh in on this thread. Where should we move the OGP-relevant parts of the discussion? My constantly beating people over the head with the Wiki link hasn't been working so far... :) > Thanks > Rob Thanks very much! Dale Innis DaleInnisEmail@gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/ce091638/attachment.htm From sempuki1 at gmail.com Fri Sep 12 17:21:57 2008 From: sempuki1 at gmail.com (Ryan McDougall) Date: Fri Sep 12 17:22:00 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: I am sorry that is not quite true. The GPL and BSD (clause<4) licenses are *not* "incompatible". Not by a long stretch. If you couple GPLed code with BSD code a vortex to the gates of hell doesn't open up, spewing forth legions of lawyers-of-the-damned. What happens when you mix the two is quite understandable and compatible -- the combined work becomes GPL, as is intended by the GPL. While it is true that OpenSim would not accept GPL code into its trunk, OpenSim has a "forge" website for precisely these kinds of projects here: http://forge.opensimulator.org/gf/ I encourage you to show your work to the OpenSim guys, and apply for a spot on opensim forge if appropriate. If you wished for your work to go into OpenSim proper, you would likely be asked to use a BSD license. Cheers, On Sat, Sep 13, 2008 at 2:55 AM, Dahlia Trimble wrote: > That wouldn't be acceptable for inclusion into Opensim then as it's > incompatible with the BSD license that Opensim uses. > > On Fri, Sep 12, 2008 at 10:49 AM, Harold Brown wrote: >> >> GPL version 2 >> http://www.psyced.org/dist/LICENSE.txt >> >> >> On Fri, Sep 12, 2008 at 10:40 AM, Dahlia Trimble >> wrote: >>> >>> PSYC looks interesting but I can't seem to find any licensing terms on >>> any of their web sites. Also looks like they haven't had much opportunity to >>> do any really large scale testing of their protocol. Anyway if they are >>> interested in working with Opensim then this thread should probably be >>> continued on the opensim-dev mailing list. Details of the list can be found >>> at https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> On Fri, Sep 12, 2008 at 10:00 AM, Harold Brown >>> wrote: >>>> >>>> lynX a developer of PSYC has just recently downloaded the OpenSIM svn >>>> and had expressed interest (yesterday) of integrating PSYC with it (totally >>>> unrelated to the conversation here) I mentioned the discussion here and they >>>> posted the following on their wiki: >>>> >>>> http://about.psyc.eu/Second_Life >>>> >>>> >>>> >>>> On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter >>>> wrote: >>>>> >>>>> On 2008-09-11, at 11:06, Robin Cornelius wrote: >>>>>> >>>>>> Is there then a call to have a different type of group. One that does >>>>>> not have chat associated with it. >>>>> >>>>> That would be point 2 in http://jira.secondlife.com/browse/SVC-2818 . >>>>> >>>>> An alternative would be to allow you to have an association with a >>>>> group that doesn't include chat or any of the other high-impact features. >>>>> There are a number of groups that I would like to "suspend membership" in >>>>> without having to re-apply to rejoin. >>>>> >>>>> See http://jira.secondlife.com/browse/SVC-1173 . >>>>> >>>>> On 2008-09-11, at 11:45, David M Chess wrote: >>>>>> >>>>>> I take it that this is a problem we'd rather not reproduce, rather >>>>>> than something that we want to make sure that an intragrid Group IM system >>>>>> also does. :) >>>>> >>>>> It's just an indication that fairly high latency for starting a group >>>>> conversation isn't automatically a fatal flaw. Certainly 10-20 seconds >>>>> latency is entirely acceptable. >>>>> >>>>>> Given the number and volume of the voices I hear raised asking for the >>>>>> limit to be increased, I think it's pretty common for people to be in 25 >>>>>> groups, for whatever reason. Not necessarily 25 groups that really need a >>>>>> group chat channel, though. >>>>> >>>>> That would be the point there. >>>>> >>>>> I'd also like to note that person-person IM and group IM are generally >>>>> different kinds of conversation, have different goals, anddon't need to >>>>> share transport. For example, I could EASILY see logging in to IRC to get >>>>> into a group chat without wanting to get into point-to-point chat with >>>>> individuals, and vice versa. >>>>> >>>>> Also, it would be nice to be able to log in to office hours with a >>>>> client that doesn't require a wide open firewall. >>>>> >>>>> Using open protocols for IM and group IM would allow me to run (for >>>>> example) a shell IRC client or XMPP client on my colo server that I'm ssh-ed >>>>> into. I can't see that happening with any likely Vivox-based client. >>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/SLDev >>>>> Please read the policies before posting to keep unmoderated posting >>>>> privileges >>>> >>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting >>>> privileges >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From edward.artaud at gmail.com Fri Sep 12 18:08:29 2008 From: edward.artaud at gmail.com (Edward Artaud) Date: Fri Sep 12 18:08:33 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080912174034.A6156113CB4@stupor.lindenlab.com> Message-ID: Maybe this is the point where an OGP list should be split off? On Fri, Sep 12, 2008 at 12:50 PM, David M Chess wrote: > Where should we move the OGP-relevant parts of the discussion? My > constantly beating people over the head with the Wiki link hasn't been > working so far... :) From dahliatrimble at gmail.com Fri Sep 12 18:32:57 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Sep 12 18:33:02 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: Please forgive the brevity of my prior response. Ryan is correct, Opensim provides a separate site where code under the GPL or other licenses that are meant to work with Opensim may be hosted if they are not chosen to be included in the core svn. If an instant messaging protocol extension could be made to work with Opensim, than that may be a good place to host it. If there were changes needed to the Opensim core in order to accomidate these extensions, then they would need to be submitted as patches and must be made available under the conditions outlined in the Contribution Policy available at: http://opensimulator.org/wiki/Contributions_Policy I'm with Rob on this discussion now, if it's pertaining to opensim then it should move off of this list and to the opensim-dev list: https://lists.berlios.de/mailman/listinfo/opensim-dev Note that GPL zealotry is *not* the goal of Opensim devs and will most likely be frowned upon in the opensim-dev list. On Fri, Sep 12, 2008 at 5:21 PM, Ryan McDougall wrote: > I am sorry that is not quite true. The GPL and BSD (clause<4) licenses > are *not* "incompatible". Not by a long stretch. If you couple GPLed > code with BSD code a vortex to the gates of hell doesn't open up, > spewing forth legions of lawyers-of-the-damned. What happens when you > mix the two is quite understandable and compatible -- the combined > work becomes GPL, as is intended by the GPL. > > While it is true that OpenSim would not accept GPL code into its > trunk, OpenSim has a "forge" website for precisely these kinds of > projects here: http://forge.opensimulator.org/gf/ > > I encourage you to show your work to the OpenSim guys, and apply for a > spot on opensim forge if appropriate. > > If you wished for your work to go into OpenSim proper, you would > likely be asked to use a BSD license. > > Cheers, > > On Sat, Sep 13, 2008 at 2:55 AM, Dahlia Trimble > wrote: > > That wouldn't be acceptable for inclusion into Opensim then as it's > > incompatible with the BSD license that Opensim uses. > > > > On Fri, Sep 12, 2008 at 10:49 AM, Harold Brown > wrote: > >> > >> GPL version 2 > >> http://www.psyced.org/dist/LICENSE.txt > >> > >> > >> On Fri, Sep 12, 2008 at 10:40 AM, Dahlia Trimble < > dahliatrimble@gmail.com> > >> wrote: > >>> > >>> PSYC looks interesting but I can't seem to find any licensing terms on > >>> any of their web sites. Also looks like they haven't had much > opportunity to > >>> do any really large scale testing of their protocol. Anyway if they are > >>> interested in working with Opensim then this thread should probably be > >>> continued on the opensim-dev mailing list. Details of the list can be > found > >>> at https://lists.berlios.de/mailman/listinfo/opensim-dev > >>> > >>> On Fri, Sep 12, 2008 at 10:00 AM, Harold Brown > >>> wrote: > >>>> > >>>> lynX a developer of PSYC has just recently downloaded the OpenSIM svn > >>>> and had expressed interest (yesterday) of integrating PSYC with it > (totally > >>>> unrelated to the conversation here) I mentioned the discussion here > and they > >>>> posted the following on their wiki: > >>>> > >>>> http://about.psyc.eu/Second_Life > >>>> > >>>> > >>>> > >>>> On Thu, Sep 11, 2008 at 10:11 PM, Argent Stonecutter > >>>> wrote: > >>>>> > >>>>> On 2008-09-11, at 11:06, Robin Cornelius wrote: > >>>>>> > >>>>>> Is there then a call to have a different type of group. One that > does > >>>>>> not have chat associated with it. > >>>>> > >>>>> That would be point 2 in http://jira.secondlife.com/browse/SVC-2818. > >>>>> > >>>>> An alternative would be to allow you to have an association with a > >>>>> group that doesn't include chat or any of the other high-impact > features. > >>>>> There are a number of groups that I would like to "suspend > membership" in > >>>>> without having to re-apply to rejoin. > >>>>> > >>>>> See http://jira.secondlife.com/browse/SVC-1173 . > >>>>> > >>>>> On 2008-09-11, at 11:45, David M Chess wrote: > >>>>>> > >>>>>> I take it that this is a problem we'd rather not reproduce, rather > >>>>>> than something that we want to make sure that an intragrid Group IM > system > >>>>>> also does. :) > >>>>> > >>>>> It's just an indication that fairly high latency for starting a group > >>>>> conversation isn't automatically a fatal flaw. Certainly 10-20 > seconds > >>>>> latency is entirely acceptable. > >>>>> > >>>>>> Given the number and volume of the voices I hear raised asking for > the > >>>>>> limit to be increased, I think it's pretty common for people to be > in 25 > >>>>>> groups, for whatever reason. Not necessarily 25 groups that really > need a > >>>>>> group chat channel, though. > >>>>> > >>>>> That would be the point there. > >>>>> > >>>>> I'd also like to note that person-person IM and group IM are > generally > >>>>> different kinds of conversation, have different goals, anddon't need > to > >>>>> share transport. For example, I could EASILY see logging in to IRC to > get > >>>>> into a group chat without wanting to get into point-to-point chat > with > >>>>> individuals, and vice versa. > >>>>> > >>>>> Also, it would be nice to be able to log in to office hours with a > >>>>> client that doesn't require a wide open firewall. > >>>>> > >>>>> Using open protocols for IM and group IM would allow me to run (for > >>>>> example) a shell IRC client or XMPP client on my colo server that I'm > ssh-ed > >>>>> into. I can't see that happening with any likely Vivox-based client. > >>>>> > >>>>> _______________________________________________ > >>>>> Policies and (un)subscribe information available here: > >>>>> http://wiki.secondlife.com/wiki/SLDev > >>>>> Please read the policies before posting to keep unmoderated posting > >>>>> privileges > >>>> > >>>> > >>>> _______________________________________________ > >>>> Policies and (un)subscribe information available here: > >>>> http://wiki.secondlife.com/wiki/SLDev > >>>> Please read the policies before posting to keep unmoderated posting > >>>> privileges > >>> > >>> > >>> _______________________________________________ > >>> Policies and (un)subscribe information available here: > >>> http://wiki.secondlife.com/wiki/SLDev > >>> Please read the policies before posting to keep unmoderated posting > >>> privileges > >> > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080912/2700e4ed/attachment-0001.htm From AndromedaQuonset at comcast.net Sat Sep 13 01:43:56 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Sat Sep 13 01:43:58 2008 Subject: [sldev] Help compiling In-Reply-To: References: <20080908035440.21A0141AFB6@stupor.lindenlab.com> Message-ID: <20080913084357.AD7FD41B442@stupor.lindenlab.com> Vector, I have had several interruptions on this project, and finally giving it another try. At the moment, I am attempting to "Do the build of the extra libraries (fmod, openjpeg, etc) into the separate tree. I've come up against a problem with this, and trying to build openjpeg. Basically, it won't build. I am using the latest stable version, which is 1.3. I am letting VS2005 convert the files, but the build is failing for a couple of reasons: I get an error message that a file named resource.h cannot be found, and I get an error that a file generated by the compiler cannot be opened with a permission denied error. I've had a few ideas about this: 1. Download and use the Windows binaries 2. Use the Unstable 2.0 release 3. Use the older 1.2 release. The wiki just says to download the latest tar file of the source. Anyone besides Vector can jump in and advise :) Andro At 02:41 AM 9/8/2008, you wrote: >I hope you've solved your problem. > >If not, maybe this will help. I'm not very experiences, so this may sound >silly. But I too created an unholy mess in my first few days trying to get >it to compile. > >It's very complicated, but the information is there on the wikis, you just >have to sort through what's not relevant, and that takes some trial and >error. What I succeeded at was the 1.20 build. > >Notice what other's have said about the python script being only for 1.21 >CMake installs. You can ignore for a MSVS2005. > >Do the build of the additional libraries you need (fmod, openjpeg, etc.) >into the separate library tree. > >Then zip that up. > >Then download all three of the zip files from the source page (check the >text on them, because sometimes the pointers on the page get messed up and >it will cause you to download mis-matched packages despite the fact you >clicked on the right link. If the links aren't there for matched package >sets, go and update the wiki to simply fix the names. I hope that made >sense.) > >Get Artwork, source, and libs from the source downloads page. > >Then unzip to a fresh directory in this order: > >1. Your created tree of library add-ons >2. Linden's artwork >3. Linden's source >4. Linden's libs. > >Those last three really don't matter what order they're in, it matters that >they come after 1, because you may find some files get replaced. These will >cause run-time errors if you don't use the ones from linden's packages. > >Once you do that and follow the converting project files wiki page you >mention, you CAN compile Release 1.20 on MSVS2005 Express. > >Good luck! > >Vector Hastings > >-----Original Message----- >From: sldev-bounces@lists.secondlife.com >[mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Andromeda >Quonset >Sent: Sunday, September 07, 2008 8:55 PM >To: sldev@lists.secondlife.com >Subject: [sldev] Help compiling > > >Greetings! > >I do not have VS2003. I have VS2002, VS2005, VS2008 Express. The >one I am _comfortable_ with is VS6.0. > >I have been attempting to compile the client. What I seem to have >accomplished is created a mess. > >I decided to use VS2005 as the best choice among the compilers I >have. The client version I chose was 1.19.1 >I am running under Windows XP SP2, 32-bit. >I have attempted to download all the myriad of files. I found I >needed to upgrade VS2005 to SP1. So, that's done. > >At one point, under "Configuring for VS2005" >http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29, >it says "To configure, go into linden\indra and run develop.py -G >VC80. This will create a build directory named build-VC80. " > >I can safely say that there is no "develop.py" in "linden\indra" or >anywhere else in the system. Nor can I find out where I might >download it from. With that lacking, I've gone to >http://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005 >where I have done the conversion manually. > >I have gotten from over 4,000 errors, to where I only have a few >errors. Much of that was from the XML code that was pre-pended >inside of the openGL headers. At the moment, I am stuck at "Link : >fatal error LNK1104: cannot open file 'dinput8.lib' > >There are other errors that appear earlier, over 250 of them, but >since linking gets invoked, I don't know if they matter or not. > >One other thing: the wiki says I need to obtain and install >something called "Microsoft Windows Server 2003 R2 Platform >SDK". This is no longer available. When you jump through all the >hoops to download it at the Microsoft site, what happens is you end >up on a download site for "Windows SDK for Windows Server 2008 and >.NET Framework 3.5". I have gone ahead and downloaded this, however, >since it isn't the version specified, I have not installed it. I >don't understand, anyway, why I would need this. I'm not running a >Windows "server" OS of any flavor here. From thordain at thordain.com Sat Sep 13 05:45:06 2008 From: thordain at thordain.com (Thordain Curtis) Date: Sat Sep 13 05:45:09 2008 Subject: [sldev] 1.21.2 Artwork pack is missing fonts? Message-ID: I just decided to start using git to merge in new source releases to my (admittedly minor) custom branch, thanks to Jacek Antonelli's excellent git repository. Have to say, the cmake build process is really smooth (first time I've built a viewer with cmake) and I'm more than impressed with how much easier it has become to build the client. In any event, I couldn't quite figure out why my newly compiled viewer refused to start. At the time I was compiling in Release mode, so I never got the interesting message about "Missing Glyph Info", the viewer instead sat in crashAndLoop() forever (wonderful function by the way ;-). It took me a few seconds to put two and two together and realise that the entire "fonts" directory is missing from the 1.21.2 artwork archive. I'm sure this might prove frustrating for new client builders, and thought I'd give a heads up in case somebody doesn't already know about this. -Thor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080913/fcc3d788/attachment.htm From robin.cornelius at gmail.com Sat Sep 13 05:58:48 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 13 05:58:57 2008 Subject: [sldev] 1.21.2 Artwork pack is missing fonts? In-Reply-To: References: Message-ID: <48CBB908.4010105@gmail.com> Thordain Curtis wrote: > I just decided to start using git to merge in new source releases to my > (admittedly minor) custom branch, thanks to Jacek Antonelli's excellent > git repository. Have to say, the cmake build process is really smooth > (first time I've built a viewer with cmake) and I'm more than impressed > with how much easier it has become to build the client. In any event, I > couldn't quite figure out why my newly compiled viewer refused to > start. At the time I was compiling in Release mode, so I never got the > interesting message about "Missing Glyph Info", the viewer instead sat > in crashAndLoop() forever (wonderful function by the way ;-). > > It took me a few seconds to put two and two together and realise that > the entire "fonts" directory is missing from the 1.21.2 artwork archive. > > The fonts should not be in the artwork directory because they are non-free and not artwork. The artwork tarball contains only linden artwork distributed under the CA-SA-3.0 licence (some also covered by Linden Trademark though). The fonts are in the libs package (where they always were) and in fact are the only thing left in the libs package now. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080913/330ab836/signature.pgp From AndromedaQuonset at comcast.net Sat Sep 13 06:08:31 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Sat Sep 13 06:08:36 2008 Subject: [sldev] Help compiling viewer Message-ID: <20080913130833.4209E41AFD1@stupor.lindenlab.com> After my previous attempts to compile the 1.19.1.4 viewer under VS2005, I basically deleted my source tree, and carefully started setting things up over again, following advice I had from last week. Most of it compiles, but I am having problems with the following items, and I hesitate to jump-in and start editing source-code which I thought was compile-able. So, I am posting my errors for another set of eyes to look at, and I welcome any and all comments. Andro 1>------ Build started: Project: lscript_compile, Configuration: Release Win32 ------ 1>Compiling... 1>lex_yy.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>ytab.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_typecheck.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_tree.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_scope.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_resource.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_error.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>lscript_bytecode.cpp 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\v3math.h(185) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llmath\llquaternion.h(153) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(138) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(138) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(157) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(157) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(225) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(225) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(232) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(232) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(239) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(239) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(260) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(260) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(267) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(267) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(274) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(274) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(281) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(281) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(310) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(310) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(385) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(385) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(582) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(582) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(722) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(722) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(752) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(752) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(1053) : error C2039: 'isfinite' : is not a member of 'std' 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\lscript\lscript_byteconvert.h(1053) : error C3861: 'isfinite': identifier not found 1>f:\secondlifesourcefiles\1_19_1_4\olibs\linden\indra\llcommon\llstringtable.h(53) : fatal error C1083: Cannot open include file: 'ext/hash_map': No such file or directory 1>Generating Code... 1>Build log was saved at "file://f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\lscript\lscript_compile\Release\BuildLog.htm" 1>lscript_compile - 122 error(s), 0 warning(s) 2>------ Skipped Build: Project: test, Configuration: Release Win32 ------ 2>Project not selected to build for this solution configuration 3>------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ 3>Executing pre-build batch file 3>master: http://secondlife.com/app/message_template/master_message_template.msg 3>current: f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\scripts\messages\message_template.msg 3>--- PASS --- 3>Older 3> in message LandStatReply: is less deprecated: NotDeprecated vs. UDPDeprecated in base 3> in message ObjectGrabUpdate: missing 1 extra blocks 3> in message ObjectScale: is less deprecated: NotDeprecated vs. Deprecated in base 3> in message ObjectGrab: missing 1 extra blocks 3> in message SimStats: missing 1 extra blocks 3> in message ObjectDeGrab: missing 1 extra blocks 3> in message ParcelObjectOwnersReply: is less deprecated: NotDeprecated vs. UDPDeprecated in base 3> in message ObjectPosition: is less deprecated: NotDeprecated vs. Deprecated in base 3> 3>PREBUILD SUCCESSFUL 3>Compiling... 3>llfilepicker.cpp 3>.\llfilepicker.cpp(172) : error C2440: '' : cannot convert from 'WCHAR [65000]' to 'llutf16string' 3> No constructor could take the source type, or constructor overload resolution was ambiguous 3>.\llfilepicker.cpp(217) : error C2440: '' : cannot convert from 'WCHAR [65000]' to 'llutf16string' 3> No constructor could take the source type, or constructor overload resolution was ambiguous 3>.\llfilepicker.cpp(237) : error C2664: 'utf16chars_to_utf8chars' : cannot convert parameter 1 from 'WCHAR *' to 'const U16 *' 3> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast 3>.\llfilepicker.cpp(263) : error C2664: 'wcsncpy' : cannot convert parameter 2 from 'const U16 *' to 'const wchar_t *' 3> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast 3>.\llfilepicker.cpp(397) : error C2440: '' : cannot convert from 'WCHAR [65000]' to 'llutf16string' 3> No constructor could take the source type, or constructor overload resolution was ambiguous 3>lldirpicker.cpp 3>.\lldirpicker.cpp(100) : error C2440: '' : cannot convert from 'WCHAR [260]' to 'llutf16string' 3> No constructor could take the source type, or constructor overload resolution was ambiguous 3>llappviewerwin32.cpp 3>f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\llwindow\llwindowwin32.cpp(2752) : error C2665: 'utf16str_to_wstring' : none of the 2 overloads could convert all the argument types 3> f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\llcommon\llstring.h(407): could be 'LLWString utf16str_to_wstring(const llutf16string &)' 3> while trying to match the argument list '(WCHAR *)' 3>f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\llwindow\llwindowwin32.cpp(3364) : error C2440: '=' : cannot convert from 'const U16 *' to 'LPCWSTR' 3> Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast 3>f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\llwindow\llwindowwin32.cpp(3779) : error C2665: 'std::basic_string<_Elem>::basic_string' : none of the 13 overloads could convert all the argument types 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(606): could be 'std::basic_string<_Elem>::basic_string(const std::basic_string<_Elem> &,unsigned int,unsigned int)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(634): or 'std::basic_string<_Elem>::basic_string(const _Elem *,unsigned int)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(655): or 'std::basic_string<_Elem>::basic_string(const _Elem *,const std::allocator<_Ty> &)' 3> with 3> [ 3> _Elem=U16, 3> _Ty=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(662): or 'std::basic_string<_Elem>::basic_string(unsigned int,_Elem)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(692): or 'std::basic_string<_Elem>::basic_string(const unsigned short *,const unsigned short *)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(703): or 'std::basic_string<_Elem>::basic_string(std::_String_const_iterator<_Elem,_Traits,_Alloc>,std::_String_const_iterator<_Elem,_Traits,_Alloc>)' 3> with 3> [ 3> _Elem=U16, 3> _Traits=std::char_traits, 3> _Alloc=std::allocator 3> ] 3> while trying to match the argument list '(const LPWSTR, unsigned long)' 3>f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\llwindow\llwindowwin32.cpp(3796) : error C2665: 'std::basic_string<_Elem>::basic_string' : none of the 13 overloads could convert all the argument types 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(606): could be 'std::basic_string<_Elem>::basic_string(const std::basic_string<_Elem> &,unsigned int,unsigned int)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(634): or 'std::basic_string<_Elem>::basic_string(const _Elem *,unsigned int)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(655): or 'std::basic_string<_Elem>::basic_string(const _Elem *,const std::allocator<_Ty> &)' 3> with 3> [ 3> _Elem=U16, 3> _Ty=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(662): or 'std::basic_string<_Elem>::basic_string(unsigned int,_Elem)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(692): or 'std::basic_string<_Elem>::basic_string(const unsigned short *,const unsigned short *)' 3> with 3> [ 3> _Elem=U16 3> ] 3> E:\Program Files\Microsoft Visual Studio 8\VC\include\xstring(703): or 'std::basic_string<_Elem>::basic_string(std::_String_const_iterator<_Elem,_Traits,_Alloc>,std::_String_const_iterator<_Elem,_Traits,_Alloc>)' 3> with 3> [ 3> _Elem=U16, 3> _Traits=std::char_traits, 3> _Alloc=std::allocator 3> ] 3> while trying to match the argument list '(const LPWSTR, unsigned long)' 3>Generating Code... 3>Build log was saved at "file://f:\SecondlifeSourceFiles\1_19_1_4\olibs\linden\indra\newview\ReleaseForDownload\BuildLog.htm" 3>newview - 10 error(s), 0 warning(s) ========== Build: 0 succeeded, 2 failed, 20 up-to-date, 1 skipped ========== From robin.cornelius at gmail.com Sat Sep 13 09:41:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 13 09:41:48 2008 Subject: [sldev] Software freedom day expo Message-ID: <48CBED46.1080307@gmail.com> Hi Everyone, I've spammed everyone else with this.. Next Saturday is software freedom day, i thought i would run an expo to celebrate software freedom and was hoping people here may wish to exhibit stuff or come along. I'm using my parcel on Hippotropolis to run this (which i hope is a good use for it as its suppose to be used for "open source" work). So if any of you have anything they want to show off/promote etc, please IM me ASAP (Michelle2 Zenovka) Lindens you too if you've got stuff would be great!. So far i have a big empty hall that needs lots of stuff and i would love to promote some of the projects we are all involved with but can't do it all on my own. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080913/9d8021bf/signature.pgp From gareth at litesim.com Sat Sep 13 09:50:14 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sat Sep 13 09:50:15 2008 Subject: [sldev] Software freedom day expo In-Reply-To: <48CBED46.1080307@gmail.com> References: <48CBED46.1080307@gmail.com> Message-ID: <61dbdd7d0809130950m7a0dff0cv2c3fa4feaff1984f@mail.gmail.com> I'd love to get a small litesim display together for this, since we're a bunch of free software fanatics :) When would you want displays ready for? On Sat, Sep 13, 2008 at 5:41 PM, Robin Cornelius wrote: > > Hi Everyone, > > I've spammed everyone else with this.. > > Next Saturday is software freedom day, i thought i would run an expo to > celebrate software freedom and was hoping people here may wish to > exhibit stuff or come along. I'm using my parcel on Hippotropolis to run > this (which i hope is a good use for it as its suppose to be used for > "open source" work). > > So if any of you have anything they want to show off/promote etc, please > IM me ASAP (Michelle2 Zenovka) > > Lindens you too if you've got stuff would be great!. So far i have a > big empty hall that needs lots of stuff and i would love to promote some > of the projects we are all involved with but can't do it all on my own. > > > Robin > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robin.cornelius at gmail.com Sat Sep 13 10:07:37 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 13 10:07:52 2008 Subject: [sldev] Software freedom day expo In-Reply-To: <61dbdd7d0809130950m7a0dff0cv2c3fa4feaff1984f@mail.gmail.com> References: <48CBED46.1080307@gmail.com> <61dbdd7d0809130950m7a0dff0cv2c3fa4feaff1984f@mail.gmail.com> Message-ID: <48CBF359.7040907@gmail.com> Well SFD08 is the 20th ie next sat so before then. Ping me in world and i will invite you to the group so you get set up at your leisure, the building is basicly up and done, just needs content! Robin Gareth Nelson wrote: > I'd love to get a small litesim display together for this, since we're > a bunch of free software fanatics :) > When would you want displays ready for? > > On Sat, Sep 13, 2008 at 5:41 PM, Robin Cornelius > wrote: >> Hi Everyone, >> >> I've spammed everyone else with this.. >> >> Next Saturday is software freedom day, i thought i would run an expo to >> celebrate software freedom and was hoping people here may wish to >> exhibit stuff or come along. I'm using my parcel on Hippotropolis to run >> this (which i hope is a good use for it as its suppose to be used for >> "open source" work). >> >> So if any of you have anything they want to show off/promote etc, please >> IM me ASAP (Michelle2 Zenovka) >> >> Lindens you too if you've got stuff would be great!. So far i have a >> big empty hall that needs lots of stuff and i would love to promote some >> of the projects we are all involved with but can't do it all on my own. >> >> >> Robin >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080913/6059349d/signature.pgp From suzyque at gmail.com Sat Sep 13 11:58:12 2008 From: suzyque at gmail.com (Suzy Deffeyes) Date: Sat Sep 13 11:59:34 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <20080912174034.A6156113CB4@stupor.lindenlab.com> Message-ID: <5928A9EE-9364-4625-8AB0-3CB484F2108D@gmail.com> Perhaps the gridnauts list? Suzy Deffeyes Sent from my iPhone On Sep 12, 2008, at 8:08 PM, "Edward Artaud" wrote: > Maybe this is the point where an OGP list should be split off? > > On Fri, Sep 12, 2008 at 12:50 PM, David M Chess > wrote: >> Where should we move the OGP-relevant parts of the discussion? My >> constantly beating people over the head with the Wiki link hasn't >> been >> working so far... :) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From robin.cornelius at gmail.com Sat Sep 13 12:03:32 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Sep 13 12:04:35 2008 Subject: [sldev] Software freedom day expo In-Reply-To: <48CBED46.1080307@gmail.com> References: <48CBED46.1080307@gmail.com> Message-ID: <48CC0E84.7060102@gmail.com> I would like to issue an apology for my mail to the list, i though it was appropriate but clearly I was wrong. Please disregard Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080913/2485585d/signature.pgp From me at signpostmarv.name Sat Sep 13 13:52:59 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sat Sep 13 13:53:05 2008 Subject: [sldev] LLSD base16/base85 support Message-ID: <48CC282B.9080309@signpostmarv.name> The current LLSD spec (not the OGP drafts) mentions optional support for base16 & base85 support. Now, some of the peeps in AW Groupies hadn't even heard of base85 till I mentioned it yesterday- do any of LL's current services use either of these optional encodings ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080913/14efadfb/smime.bin From tao.takashi at googlemail.com Sat Sep 13 14:36:29 2008 From: tao.takashi at googlemail.com (Christian Scholz / Tao Takashi (SL)) Date: Sat Sep 13 14:36:31 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <5928A9EE-9364-4625-8AB0-3CB484F2108D@gmail.com> References: <20080912174034.A6156113CB4@stupor.lindenlab.com> <5928A9EE-9364-4625-8AB0-3CB484F2108D@gmail.com> Message-ID: <23bbb49e0809131436v2219e09ameff6f4104a53a211@mail.gmail.com> On Sat, Sep 13, 2008 at 8:58 PM, Suzy Deffeyes wrote: > Perhaps the gridnauts list? I tried this in the past but the gridnauts list now seems to be more about bears. I also still don't get the reason why a lively discussion should be moved to a bugtracker. Usually you would think that the opposite direction makes sense ;-) Summaries should be put on the bugtracker or the wiki IMHO, not the discussions. Of course there is also always the possibility to just create a Google group or something for it but I wonder if this will work either. But maybe let's try gridnauts for now and I will make sure that it will be included on gmane for easier reading (but maybe after my vacation which starts next week). -- Tao > Suzy Deffeyes > > Sent from my iPhone > > On Sep 12, 2008, at 8:08 PM, "Edward Artaud" > wrote: > >> Maybe this is the point where an OGP list should be split off? >> >> On Fri, Sep 12, 2008 at 12:50 PM, David M Chess wrote: >>> >>> Where should we move the OGP-relevant parts of the discussion? My >>> constantly beating people over the head with the Wiki link hasn't been >>> working so far... :) >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Christian Scholz Tao Takashi (Second Life name) taotakashi@gmail.com Blog/Podcast: http://mrtopf.de/blog Planet: http://worldofsl.com Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T From robla at lindenlab.com Sat Sep 13 15:06:53 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Sep 13 15:06:56 2008 Subject: [sldev] Software freedom day expo In-Reply-To: <48CC0E84.7060102@gmail.com> References: <48CBED46.1080307@gmail.com> <48CC0E84.7060102@gmail.com> Message-ID: <48CC397D.4080505@lindenlab.com> On 09/13/2008 12:03 PM, Robin Cornelius wrote: > I would like to issue an apology for my mail to the list, i though it > was appropriate but clearly I was wrong. > > Please disregard > Robin and I discussed this offlist after Robin received a few complaints. I suggested that the only faux pas I saw was in not redirecting the discussion traffic to an alternate public forum. So, here's the main page: http://wiki.secondlife.com/wiki/User:Michelle2_Zenovka/SFD08_at_Hippotropolis ...and here's the (currently empty) discussion page to direct comments about this event to: http://wiki.secondlife.com/wiki/User_talk:Michelle2_Zenovka/SFD08_at_Hippotropolis If you want to discuss the mailing list policy, please direct those comments here: http://wiki.secondlife.com/wiki/Talk:SLDev Thanks Rob From gareth at litesim.com Sat Sep 13 16:01:02 2008 From: gareth at litesim.com (Gareth Nelson) Date: Sat Sep 13 16:01:04 2008 Subject: [sldev] LLSD base16/base85 support In-Reply-To: <48CC282B.9080309@signpostmarv.name> References: <48CC282B.9080309@signpostmarv.name> Message-ID: <61dbdd7d0809131601p6251d16bh24d09e849fc8ceff@mail.gmail.com> As far as i'm aware, the sample python code and llcommon/llsd.cpp both totally lack this support. On Sat, Sep 13, 2008 at 9:52 PM, SignpostMarv Martin wrote: > The current LLSD spec (not the OGP drafts) mentions optional support for > base16 & base85 support. > > Now, some of the peeps in AW Groupies hadn't even heard of base85 till I > mentioned it yesterday- do any of LL's current services use either of these > optional encodings ? > > ~ Marv. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From ian at ianbetteridge.co.uk Sun Sep 14 06:47:26 2008 From: ian at ianbetteridge.co.uk (Ian Betteridge) Date: Sun Sep 14 06:47:34 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <23bbb49e0809131436v2219e09ameff6f4104a53a211@mail.gmail.com> References: <20080912174034.A6156113CB4@stupor.lindenlab.com> <5928A9EE-9364-4625-8AB0-3CB484F2108D@gmail.com> <23bbb49e0809131436v2219e09ameff6f4104a53a211@mail.gmail.com> Message-ID: On Sat, Sep 13, 2008 at 10:36 PM, Christian Scholz / Tao Takashi (SL) wrote: > I also still don't get the reason why a lively discussion should be > moved to a bugtracker. Usually you would think that the opposite > direction makes sense ;-) Summaries should be put on the bugtracker or > the wiki IMHO, not the discussions. Yes, I think Tao is completely right with this. Bugtrackers don't make for decent discussion - it's not what they're designed for. Mailing lists, on the other hand, are perfect for discussion. Plus, of course, as someone else pointed out discussion of requirements should be a precursor to actually creating something, not come afterwards. Otherwise you end up with systems which work perfectly for, say, 20 concurrent users but which fall over because you haven't considered what would happen when you have 200 concurrent users. From drscofield at xyzzyxyzzy.net Sun Sep 14 10:43:34 2008 From: drscofield at xyzzyxyzzy.net (dr scofield) Date: Sun Sep 14 10:43:48 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> References: <20080806190044.302881139C9@stupor.lindenlab.com> <80B4D54E-C127-454E-BD78-2EAD504D5D05@gmail.com> <48C12289.70706@weblogsinc.com> <2BDCE14E-89B0-4904-9CF8-C8241253F4EB@gmail.com> <34cc66250809060956n302bd1d7y985fedcd5f939e6b@mail.gmail.com> <64604F40-E41E-49A4-A577-6C9F64BAC90F@gmail.com> Message-ID: <48CD4D46.5090703@xyzzyxyzzy.net> Argent Stonecutter wrote: > On 2008-09-06, at 11:56, Teravus Ovares wrote: >> There are little nuances that make direct transition to XMPP more >> challenging then just switching. > > Agreed, but... and this is the important things... this has nothing to > do with *switching* to XMPP. They aren't *switching* to SLim, they are > simply using the Vivox software in parallel, embedded in the SL client. are they using it for chat or for IM or both? cheers, dr scofield -- dr dirk husemann ---- math & computer science ---- ibm zurich research lab RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofield@xyzzyxyzzy.net --------------------- http://xyzzyxyzzy.net/ From drscofield at xyzzyxyzzy.net Sun Sep 14 10:48:10 2008 From: drscofield at xyzzyxyzzy.net (dr scofield) Date: Sun Sep 14 10:48:23 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <48C20926.4030506@cox.net> Message-ID: <48CD4E5A.805@xyzzyxyzzy.net> Edward Artaud wrote: > Clearly there's some change in roadmap implied by the introduction of > SLim that these OGP plans aren't taking into consideration. > so, question: what is the purpose of SLim? is it similarly "open" as the voice stuff is? -- dr dirk husemann ---- math & computer science ---- ibm zurich research lab RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofield@xyzzyxyzzy.net --------------------- http://xyzzyxyzzy.net/ From drscofield at xyzzyxyzzy.net Sun Sep 14 11:05:12 2008 From: drscofield at xyzzyxyzzy.net (dr scofield) Date: Sun Sep 14 11:05:37 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: References: <69E35CBB-3BB7-4B12-9B1B-8705D6CD06B4@gmail.com> <05E835E4-64A9-4F5D-BBC8-20E1E41CED56@gmail.com> Message-ID: <48CD5258.9080707@xyzzyxyzzy.net> Ryan McDougall wrote: > I am sorry that is not quite true. The GPL and BSD (clause<4) licenses > are *not* "incompatible". Not by a long stretch. If you couple GPLed > code with BSD code a vortex to the gates of hell doesn't open up, > spewing forth legions of lawyers-of-the-damned. What happens when you > mix the two is quite understandable and compatible -- the combined > work becomes GPL, as is intended by the GPL. > and not intended by OpenSim. > While it is true that OpenSim would not accept GPL code into its > trunk, OpenSim has a "forge" website for precisely these kinds of > projects here: http://forge.opensimulator.org/gf/ > yep! > I encourage you to show your work to the OpenSim guys, and apply for a > spot on opensim forge if appropriate. > > If you wished for your work to go into OpenSim proper, you would > likely be asked to use a BSD license. > s/likely/certainly/ or go the mysql license exceptions route. cheers, dr scofield -- dr dirk husemann ---- math & computer science ---- ibm zurich research lab RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofield@xyzzyxyzzy.net --------------------- http://xyzzyxyzzy.net/ From AndromedaQuonset at comcast.net Sun Sep 14 22:15:14 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Sun Sep 14 22:15:10 2008 Subject: [sldev] Help compiling Message-ID: <20080915051508.79C6641B115@stupor.lindenlab.com> I found where somebody had made the binaries available, so I used them. I still have 2 files that won't compile. I don't know if the problem lies in errors in the files themselves, or if some dependency is still not being met. I attempted to summarize what I was seeing, gave up, and posted the VS2005 output screen instead. So far, nobody has responded. Thanks, Vector! At 03:34 PM 9/14/2008, you wrote: >I'm pretty sure I had the same problem and I just downloaded the binaries. > >Since in my case I have no need to touch the functionality of that library, >it works for me. > >It sounds like from your later post you were able to get it compiled. Yes? > >I could never get the test version to compile. > >Is this showing that you can't get the release version to compile? My >computer is offline, I think the one I can compile is release and release >for download. > >Not much help, I figure. Sorry. > >Vector. From gigstaggart at gmail.com Mon Sep 15 02:41:53 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Sep 15 02:42:09 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48CD4E5A.805@xyzzyxyzzy.net> References: <48C20926.4030506@cox.net> <48CD4E5A.805@xyzzyxyzzy.net> Message-ID: <48CE2DE1.7020701@gmail.com> dr scofield wrote: > Edward Artaud wrote: >> Clearly there's some change in roadmap implied by the introduction of >> SLim that these OGP plans aren't taking into consideration. >> > so, question: what is the purpose of SLim? is it similarly "open" as the > voice stuff is? > Apparently SLim has no role in the future of open grid, except in so far as it is another thing that will break when we change things. Rob has assured me that these proprietary vivox protocols are not part of any long term strategy. Which does make you wonder why anyone would invest in a dead end, but Linden works in mysterious ways. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080915/eb2d10de/smime.bin From pete.pinter at gmail.com Mon Sep 15 12:28:21 2008 From: pete.pinter at gmail.com (Pete Pinter) Date: Mon Sep 15 12:28:28 2008 Subject: [sldev] [VWR-9016] Still missing "Info.plist" in 1-21-2-r96080 Message-ID: <48CEB755.8050300@gmail.com> Hi, I'm unable to create a cmake 2.6.2rc4 config for Xcode 3.1 with the 1-21-2-r96080 downloads. Reading [VWR-9016], I read it that Soft's fix for this would be in the next source drop, but is that a SVN branch somewhere, rather than the downloadable tarballs? Sorry, I'm new here :) Thanks, Pete ------------------------ mainframe:indra pinter$ ./develop.py Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" \'/Users/pinter/Desktop/Mac_Development/SL_1-21-2/linden/indra\'' in 'build-darwin-i386' -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Version of viewer is 1.21.2.0 -- Configuring done CMake Error in mac_crash_logger/CMakeLists.txt: Cannot find source file "Info.plist". Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error in mac_updater/CMakeLists.txt: Cannot find source file "Info.plist". Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx -- Build files have been written to: /Users/pinter/Desktop/Mac_Development/SL_1-21-2/linden/indra/build-darwin-i386 Cleaning 'build-darwin-i386' Traceback (most recent call last): File "./develop.py", line 676, in main(sys.argv[1:]) File "./develop.py", line 646, in main setup.run_cmake() File "./develop.py", line 156, in run_cmake self.run(cmd, 'cmake') File "./develop.py", line 136, in run (name, event, status)) __main__.CommandError: the command 'cmake' exited with status 1 From lenglish5 at cox.net Mon Sep 15 13:07:23 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 15 13:07:25 2008 Subject: [sldev] Question: Replacing current group chat with XMPP? In-Reply-To: <48CE2DE1.7020701@gmail.com> References: <48C20926.4030506@cox.net> <48CD4E5A.805@xyzzyxyzzy.net> <48CE2DE1.7020701@gmail.com> Message-ID: <48CEC07B.6010503@cox.net> Just redirecting the discussion to Dale Innis' page. https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP I believe that Tess wants to devote ab AW Groupies meeting and/or Zero Lnden office hours to the topic of IM sometime this week. My own thoughts: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#implement_current_group_IM_in_the_Agent_Domain_as_the_behavioral_use-case_for_any_new_architecture and a long winded irc transcript on the topic: https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/pyogp_irc-2008_09_14 Lawson From tess at lindenlab.com Mon Sep 15 13:10:56 2008 From: tess at lindenlab.com (Tess Chu) Date: Mon Sep 15 13:11:12 2008 Subject: [sldev] [AWG] Question: Replacing current group chat with XMPP? In-Reply-To: <48CE2DE1.7020701@gmail.com> References: <48C20926.4030506@cox.net> <48CD4E5A.805@xyzzyxyzzy.net> <48CE2DE1.7020701@gmail.com> Message-ID: <48CEC150.8080302@lindenlab.com> Apologies for chiming in so late on this thread. It's now tagged as [AWG] for filtering. The introduction to SLim did not imply any change in roadmap for OGP. As Joe stated earlier SLim was designed to "support SL group channels and proximal voice channels, both of which are fairly unique communication abstractions for Second Life." While there are text components to SLim, it primarily addresses the voice components of Second Life. The Open Platform team is working on the longer term solution of using standard protocols to enable interoperable, scalable messaging across virtual worlds. Dale Innis' wiki page does an awesome job capturing discussion on this topic: http://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP. We also recognize that there is a great deal of interest in Jabber/XMPP as a solution for chat both on the Second Life Grid and for interoperation with other virtual worlds. There is, as RobLa pointed out earlier, a PJIRA task for this: https://jira.secondlife.com/browse/SVC-419. However, there are specific concerns that XMPP alone is not sufficient for the existing and proposed use cases: * XMPP as a backend solution to Group Chat has not been proven to scale * Authentication & identity needs to work across all grids with all services (search, resource discovery, commerce, and currency.) How does JabberID map to use cases of existing UUID? * Are we talking about XMPP as a general solution to messaging or just for chat? * On the client -> server side, adding XMPP to OGP on the client is a little heavy because we would need XMPP stacks With these thoughts in mind, please join us at the AWG meeting tomorrow where the topic will be "Solutions to Interoperble Chat." Tess & Whump Jason Giglio wrote: > dr scofield wrote: > >> Edward Artaud wrote: >> >>> Clearly there's some change in roadmap implied by the introduction of >>> SLim that these OGP plans aren't taking into consideration. >>> >>> >> so, question: what is the purpose of SLim? is it similarly "open" as the >> voice stuff is? >> >> > > Apparently SLim has no role in the future of open grid, except in so far > as it is another thing that will break when we change things. Rob has > assured me that these proprietary vivox protocols are not part of any > long term strategy. > > Which does make you wonder why anyone would invest in a dead end, but > Linden works in mysterious ways. > > -Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From lenglish5 at cox.net Mon Sep 15 13:19:19 2008 From: lenglish5 at cox.net (Lawson English) Date: Mon Sep 15 13:19:22 2008 Subject: [sldev] Discussion about group IM Message-ID: <48CEC347.8010707@cox.net> Tess and Whump want to have a meeting or 2 about group IM this week. At AWG and/or Zero's office hours, etc. I won't be able to make the AW Groupies meeting on Tuesday, but I've added thoughts to Dale Innis's page: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP my own two cents: https://wiki.secondlife.com/wiki/User:Dale_Innis/Group_IM_in_OGP#implement_current_group_IM_in_the_Agent_Domain_as_the_behavioral_use-case_for_any_new_architecture a long winded irc transcript on the topic: https://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/pyogp_irc-2008_09_14 Lawson From soft at lindenlab.com Mon Sep 15 13:31:41 2008 From: soft at lindenlab.com (Soft) Date: Mon Sep 15 13:31:44 2008 Subject: [sldev] [VWR-9016] Still missing "Info.plist" in 1-21-2-r96080 In-Reply-To: <48CEB755.8050300@gmail.com> References: <48CEB755.8050300@gmail.com> Message-ID: Yes. There was a merge error that means the RC2 release doesn't have it on the exact revision. You can get the URLs for more recent tarballs here: http://svn.secondlife.com/svn/linden/branches/viewer_1-21/doc/asset_urls.txt The RC3 tarball version will have the Mac files in place. On Mon, Sep 15, 2008 at 2:28 PM, Pete Pinter wrote: > Hi, > > I'm unable to create a cmake 2.6.2rc4 config for Xcode 3.1 with the > 1-21-2-r96080 downloads. > > Reading [VWR-9016], I read it that Soft's fix for this would be in the next > source drop, but is that a SVN branch somewhere, rather than the > downloadable tarballs? > > Sorry, I'm new here :) > > Thanks, > Pete > > ------------------------ > > mainframe:indra pinter$ ./develop.py > Running 'cmake -G \'Xcode\' -DCMAKE_BUILD_TYPE:STRING=RELWITHDEBINFO > -DSTANDALONE:BOOL=FALSE -DUNATTENDED:BOOL=FALSE "" > \'/Users/pinter/Desktop/Mac_Development/SL_1-21-2/linden/indra\'' in > 'build-darwin-i386' > -- The C compiler identification is GNU > -- The CXX compiler identification is GNU > -- Check for working C compiler: /usr/bin/gcc > -- Check for working C compiler: /usr/bin/gcc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Check for working CXX compiler: /usr/bin/g++ > -- Check for working CXX compiler: /usr/bin/g++ -- works > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Version of viewer is 1.21.2.0 > -- Configuring done > CMake Error in mac_crash_logger/CMakeLists.txt: > Cannot find source file "Info.plist". Tried extensions .c .C .c++ .cc .cpp > .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx > > > CMake Error in mac_updater/CMakeLists.txt: > Cannot find source file "Info.plist". Tried extensions .c .C .c++ .cc .cpp > .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx > > > -- Build files have been written to: > /Users/pinter/Desktop/Mac_Development/SL_1-21-2/linden/indra/build-darwin-i386 > Cleaning 'build-darwin-i386' > Traceback (most recent call last): > File "./develop.py", line 676, in > main(sys.argv[1:]) > File "./develop.py", line 646, in main > setup.run_cmake() > File "./develop.py", line 156, in run_cmake > self.run(cmd, 'cmake') > File "./develop.py", line 136, in run > (name, event, status)) > __main__.CommandError: the command 'cmake' exited with status 1 > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From aimee at ama-zing.co.uk Tue Sep 16 05:53:31 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Tue Sep 16 05:53:36 2008 Subject: [sldev] [Mac] Xcode 3.1 / CMake 2.6 and Info.plist files Message-ID: I am finding I need to apply the attached patch to make things build on Xcode 3.1 without giving errors about the Info.plist files for mac- updater and mac-crash-logger (this is not the same problem as in another thread). I assume this is only happening under 3.1, as no one's complained about it before with 3.0? I don't have 3.0 handy to test. The CMakeLists.txt files for both include the pre-prepared Info.plist as resource file, then this to copy it to the bundle: set_source_files_properties( Info.plist PROPERTIES MACOSX_PACKAGE_LOCATION . # will it blend? + poppy ) The answer seems to be "No" if you're using Xcode 3.1 Poppy :) It conflicts with the rule that gets created to produce the Info.plist from a template. This will make CMake use the existing file as the template: set_target_properties(mac-updater PROPERTIES MACOSX_BUNDLE_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist ) ... but I think that only works under CMake 2.6. Aimee. -------------- next part -------------- Skipped content of type multipart/mixed From grant at lindenlab.com Tue Sep 16 09:44:31 2008 From: grant at lindenlab.com (Grant Linden) Date: Tue Sep 16 09:44:35 2008 Subject: [sldev] RX Office hours - Elidor Paslong will be presenting a social networking application for Second Life called "Spider" Message-ID: <907af5560809160944y55c5165djbac7abf44c656780@mail.gmail.com> At RX Office hours this week Elidor Paslong will be presenting a social networking application for Second Life called "Spider" http://spider.secondplaces.net Thursday September 18th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080916/a3e3b392/attachment-0001.htm From tom at streamsense.net Tue Sep 16 10:06:51 2008 From: tom at streamsense.net (Thomas Grimshaw) Date: Tue Sep 16 10:07:02 2008 Subject: [sldev] RX Office hours - Elidor Paslong will be presenting a social networking application for Second Life called "Spider" In-Reply-To: <907af5560809160944y55c5165djbac7abf44c656780@mail.gmail.com> References: <907af5560809160944y55c5165djbac7abf44c656780@mail.gmail.com> Message-ID: <48CFE7AB.4050003@streamsense.net> Grant Linden wrote: > At RX Office hours this week Elidor Paslong will be presenting a > social networking application for Second Life called "Spider" > http://spider.secondplaces.net I just checked this out. A very interesting project.. "profiling" avatars based on their personality and characteristics. Unfortunately the second life signup is currently broken. But i advise anyone interested in social development in virtual worlds to check this out. Tom From AndromedaQuonset at comcast.net Tue Sep 16 15:52:22 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Tue Sep 16 15:54:35 2008 Subject: [sldev] Re: recoppiling all scripts in an object makes scripts set as not running run again Message-ID: <20080916225433.D274E41B496@stupor.lindenlab.com> At 02:48 PM 9/16/2008, you wrote: >On Tue, Sep 16, 2008 at 1:21 PM, Tigro Spottystripes > wrote: > > the other day I tried converting an object of mine to be full Mono and I > > noticed all scripts set to not-running prior to the object wide recopile > > started to run again, is this supposed to happen? (I also noted > that several > > scripts were not found, and amazingly one script that used to not be found > > now is) > >Recompiling will set them as running again, yes. Back when "Set >Scripts in Selection to Running" wasn't working, I would use the >compile option as a workaround. It would take longer, but have the >same effect. > >Now that setting scripts to running works, you can probably get away >with adding a jira to make recompiling preserve the running state. > >-Stickman I think it would be un-wise to make compiling preserve the running state. There is already a problem with reset not clearing the running state, and the only solution being to recompile the script, something which doesn't work for customers who do not have recompile-permissions to scripts, but now you want to make it absolutely impossible to clear the running state by anyone anywhere? From AndromedaQuonset at comcast.net Tue Sep 16 16:18:40 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Tue Sep 16 16:20:52 2008 Subject: [sldev] Re: recoppiling all scripts in an object makes scripts set as not running run again In-Reply-To: <20080916225433.D274E41B496@stupor.lindenlab.com> References: <20080916225433.D274E41B496@stupor.lindenlab.com> Message-ID: <20080916232051.66E1E41B379@stupor.lindenlab.com> At 04:52 PM 9/16/2008, you wrote: >At 02:48 PM 9/16/2008, you wrote: >>On Tue, Sep 16, 2008 at 1:21 PM, Tigro Spottystripes >> wrote: >> > the other day I tried converting an object of mine to be full Mono and I >> > noticed all scripts set to not-running prior to the object wide recopile >> > started to run again, is this supposed to happen? (I also noted >> that several >> > scripts were not found, and amazingly one script that used to not be found >> > now is) >> >>Recompiling will set them as running again, yes. Back when "Set >>Scripts in Selection to Running" wasn't working, I would use the >>compile option as a workaround. It would take longer, but have the >>same effect. >> >>Now that setting scripts to running works, you can probably get away >>with adding a jira to make recompiling preserve the running state. >> >>-Stickman > >I think it would be un-wise to make compiling preserve the running state. >There is already a problem with reset not clearing the running >state, and the only solution being to recompile the script, >something which doesn't work for customers who do not have >recompile-permissions to scripts, but now you want to >make it absolutely impossible to clear the running state by anyone anywhere? I see where I have misunderstood "running state" with "running" state. I was concerned with the "running state" in reference to using the compiler to recompile a script in order to clear current variables, and return the script to default_state, rather than whether the script was set for running or not. I have just added what I hope is a useful comment to http://jira.secondlife.com/browse/SVC-2987 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080916/cc48de03/attachment.htm From AndromedaQuonset at comcast.net Tue Sep 16 16:25:42 2008 From: AndromedaQuonset at comcast.net (Andromeda Quonset) Date: Tue Sep 16 16:27:55 2008 Subject: [sldev] Re: recoppiling all scripts in an object makes scripts set as not running run again In-Reply-To: <20080916232051.66E1E41B379@stupor.lindenlab.com> References: <20080916225433.D274E41B496@stupor.lindenlab.com> <20080916232051.66E1E41B379@stupor.lindenlab.com> Message-ID: <20080916232754.B08C6113BB0@stupor.lindenlab.com> Please disregard the last 2 posts, as they should have gone into a different list (very red-faced). Sorry everyone! From whump at lindenlab.com Tue Sep 16 17:40:25 2008 From: whump at lindenlab.com (Bill Humphries) Date: Tue Sep 16 17:40:28 2008 Subject: [sldev] [Announce] OpenGrid List Now Available Message-ID: <636243CE-0F06-4E5A-BF75-E0A550CD6729@lindenlab.com> I have opened a new mailing list, OpenGrid@lists.secondlife.com, for discussions of software design and architecture related to the Architecture Working Group and the OpenGrid protocol. These discussions have needed a home, and neither SLDev or Gridnauts were the best place for them. Please read https://wiki.secondlife.com/wiki/OpenGrid_Mailing_List for subscription info and list policies. RobLa and I will scold and nudge OGP-related discussion on SLDev to the new list. --- Whump Linden is Bill Humphries || whump@lindenlab.com || http://secondlife.com/ From soft at lindenlab.com Wed Sep 17 11:58:54 2008 From: soft at lindenlab.com (Soft) Date: Wed Sep 17 11:58:57 2008 Subject: [sldev] Thursday Open Source Meeting agenda Message-ID: If you've got something you'd like to discuss at tomorrow's open source meeting, head on over to https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda and drop it in. Thanks! From tongb at ohio.edu Wed Sep 17 13:15:39 2008 From: tongb at ohio.edu (Bruce Tong) Date: Wed Sep 17 13:15:42 2008 Subject: [sldev] Nvidia 3D Goggles? Message-ID: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> I found this article on Slashdot. I refers to Nvidia 3D Goggles. Will this kind of thing be an option for SL? Graphical issues aren't my strong suit, so I thought I'd see what y'all had to say. According to the FAQ, there's DirectX support now, OpenGL promised later. Would there be other issues? http://www.maximumpc.com/article/features/everything_you_need_know_about_nvidia%E2%80%99s_3d_goggle_gamble?page=0%2C0 Reference: http://tech.slashdot.org/tech/08/09/17/1530202.shtml -- Bruce Tong Software Engineer Office of Information Technology Ohio University From brad at lindenlab.com Wed Sep 17 15:05:38 2008 From: brad at lindenlab.com (Brad Kittenbrink (Brad Linden)) Date: Wed Sep 17 15:05:38 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> Message-ID: <48D17F32.9000903@lindenlab.com> Bruce Tong wrote: > I found this article on Slashdot. I refers to Nvidia 3D Goggles. Will > this kind of thing be an option for SL? Graphical issues aren't my > strong suit, so I thought I'd see what y'all had to say. According to > the FAQ, there's DirectX support now, OpenGL promised later. Would > there be other issues? > > http://www.maximumpc.com/article/features/everything_you_need_know_about_nvidia%E2%80%99s_3d_goggle_gamble?page=0%2C0 > > Reference: > http://tech.slashdot.org/tech/08/09/17/1530202.shtml > > Work on a stereoscopic rendering patch for the viewer has been going on under https://jira.secondlife.com/browse/VWR-2972 but I haven't been doing a good job of keeping track of progress lately. The focus has been mostly on anaglyph stereo rendering, but it could possibly be adapted to other stereo displays. The main issue is that after impostors were introduced, we've been using a bunch of render to texture all over the place, so dropping in stereo won't 'just work' in current viewers. A problem that will only get worse if/when the shadow-draft branch gets beyond the draft stage. The patch as written against 1.18.2.1 would likely apply relatively cleanly to 1.19.0.x series viewers. So those might work with the nVidia goggles when they release OpenGL support. -Brad From whump at lindenlab.com Wed Sep 17 16:05:06 2008 From: whump at lindenlab.com (Bill Humphries) Date: Wed Sep 17 16:05:08 2008 Subject: [sldev] [AWG] Question: Replacing current group chat with XMPP? In-Reply-To: <48CEC150.8080302@lindenlab.com> References: <48C20926.4030506@cox.net> <48CD4E5A.805@xyzzyxyzzy.net><48CE2DE1.7020701@gmail.com> <48CEC150.8080302@lindenlab.com> Message-ID: <348F37BC-B04F-4CAB-A2B2-96BAF211FBC2@lindenlab.com> We've moved this discussion to the new OpenGrid mailing list for closure. The summary is at: https://lists.secondlife.com/pipermail/opengrid/2008-September/000003.html -- whump From alissa_sabre at yahoo.co.jp Wed Sep 17 17:31:01 2008 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Wed Sep 17 17:31:08 2008 Subject: SL Fonts (was: [sldev] 1.21.2 Artwork pack is missing fonts?) In-Reply-To: <48CBB908.4010105@gmail.com> Message-ID: <1kw8s0bdtadv4ds8mi628J9w.alissa_sabre@yahoo.co.jp> Excuse me for hijacking the thread, but... > The fonts should not be in the artwork directory because they are > non-free and not artwork. > The fonts are in the libs package (where they > always were) and in fact are the only thing left in the libs package now. Why does Linden SL viewer come with the fonts? (As opposed to using platforms' standard fonts.) I know typical games have their own fonts, but SL is not a game, and I don't think major reasons for the games apply to SL. On the other hands, I have several downsides of the current SL fonts. * They are very incomplete in glyph coverage. * There is no guarantee the design of SL fonts matches with the fallback fonts. * Pango has some difficulties to handle those fonts. (Yes, this is my main concern. No, pango adaptation in SL viewer is still on a long way.) and, * The license of the fonts makes source distribution somewhat complicated. (This issue is from the original thread.) What happens if we completely discard the font files from the SL distribution and let the viewer use platforms' standard fonts? Alissa Sabre -------------------------------------- Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more! http://pr.mail.yahoo.co.jp/mlb/ From dmahalko at gmail.com Wed Sep 17 22:29:05 2008 From: dmahalko at gmail.com (Dale Mahalko) Date: Wed Sep 17 22:29:07 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D17F32.9000903@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> Message-ID: While I have not looked at the code for render-to-texture, it sounds to me like it could be fairly easily updated to work properly with stereoscopic viewers. The code just needs to run a second time to make stereoscopic image pairs with depth perception. Rather than making one "impostor in the middle" as for the current single-eye viewer that offers no depth perception, it would make two impostors, each rendered slightly offset to the left and right of the center camera view and aligning with the stereo viewer's eye separation distance. - Dale On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) wrote: > > The main issue is that after impostors were introduced, we've been using a > bunch of render to texture all over the place, so dropping in stereo won't > 'just work' in current viewers. A problem that will only get worse if/when > the shadow-draft branch gets beyond the draft stage. From chaosstar at gmail.com Thu Sep 18 01:07:39 2008 From: chaosstar at gmail.com (Ambrosia) Date: Thu Sep 18 01:07:43 2008 Subject: [sldev] Curious about latest trunk update/LLSD changes/Inventory Service Message-ID: <9bb32d430809180107h49166c18sd65f12d546910ac4@mail.gmail.com> Greetings! This is mostly aimed at Soft Linden, but for those who are interested, check the latest trunk changeset: http://svn.secondlife.com/trac/linden/changeset/1193 Among the things that caught my curiosity is binary support for llsd, and what seems to be an Agent Inventory Service. What we see are the new capabilities FetchInventory WebFetchInventoryDescendants FetchLib FetchLibDescendants I'm just curious about what's being worked on here, as it seems to be quite a change in the inventory backend or its connections :> --Chalice Yao From tofu.linden at lindenlab.com Thu Sep 18 02:43:45 2008 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Sep 18 02:43:48 2008 Subject: [sldev] Curious about latest trunk update/LLSD changes/InventoryService In-Reply-To: <9bb32d430809180107h49166c18sd65f12d546910ac4@mail.gmail.com> References: <9bb32d430809180107h49166c18sd65f12d546910ac4@mail.gmail.com> Message-ID: <48D222D1.9030103@lindenlab.com> Ambrosia wrote: > What we see are the new capabilities > > FetchInventory > WebFetchInventoryDescendants > FetchLib > FetchLibDescendants > > I'm just curious about what's being worked on here, as it seems to be > quite a change in the inventory backend or its connections :> I've not been involved in that, but if I remember correctly the new capabilities allow the inventory data to be bulk-transferred over TCP instead of trickling over the circuit code in tiny fragments. This, I believe, is intended to improve reliability (and speed) of inventory-loading, eliminating a cause of *perceived* inventory loss. There may be other goodies in there... -tofu From secret.argent at gmail.com Thu Sep 18 05:19:08 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 18 05:19:07 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> Message-ID: <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> On 2008-09-18, at 00:29, Dale Mahalko wrote: > Rather than making one "impostor in the middle" as for the current > single-eye viewer that offers no depth perception, it would make two > impostors, each rendered slightly offset to the left and right of the > center camera view and aligning with the stereo viewer's eye > separation distance. Two comments: 1. It would be nice to be able to run a "two camera" view even without stereo, with one view as a "peripheral vision" view (overhead, say, or fisheye) in a picture-in-a-picture spot or even (radical idea) a second window. 2. You know what would be cool for 3d? A control to dynamically adjust the 3d separation, like the current "zoom" control. Yes, it's not realistic, who cares? It's virtual. From lenglish5 at cox.net Thu Sep 18 08:17:34 2008 From: lenglish5 at cox.net (Lawson English) Date: Thu Sep 18 08:17:37 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> Message-ID: <48D2710E.1020901@cox.net> Argent Stonecutter wrote: > On 2008-09-18, at 00:29, Dale Mahalko wrote: >> Rather than making one "impostor in the middle" as for the current >> single-eye viewer that offers no depth perception, it would make two >> impostors, each rendered slightly offset to the left and right of the >> center camera view and aligning with the stereo viewer's eye >> separation distance. > > Two comments: > > 1. It would be nice to be able to run a "two camera" view even without > stereo, with one view as a "peripheral vision" view (overhead, say, or > fisheye) in a picture-in-a-picture spot or even (radical idea) a > second window. > Its a possible use case. Submit it somewhere. > 2. You know what would be cool for 3d? A control to dynamically adjust > the 3d separation, like the current "zoom" control. Yes, it's not > realistic, who cares? It's virtual. > See above. Seriously, with capability-based data transfer, it should be possible to request optional streams of data for specialized viewers that support these optional streams (e.g. different camera view), just as limited clients will be able to NOT receive specific data streams as the OGP matures and is incorporated into the SL main grid. Lawson From dahliatrimble at gmail.com Thu Sep 18 08:23:21 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu Sep 18 08:23:23 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D2710E.1020901@cox.net> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> Message-ID: On Thu, Sep 18, 2008 at 8:17 AM, Lawson English wrote: > Argent Stonecutter wrote: > >> >> > > 2. You know what would be cool for 3d? A control to dynamically adjust the >> 3d separation, like the current "zoom" control. Yes, it's not realistic, who >> cares? It's virtual. >> >> See above. > > > Seriously, with capability-based data transfer, it should be possible to > request optional streams of data for specialized viewers that support these > optional streams (e.g. different camera view), just as limited clients will > be able to NOT receive specific data streams as the OGP matures and is > incorporated into the SL main grid. > > > Sounds to me like it's something that would be implemented entirely client side -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080918/04272f5c/attachment-0001.htm From jhurliman at jhurliman.org Thu Sep 18 13:06:37 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Thu Sep 18 13:06:41 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? Message-ID: I know that the DiscardLevel field in the RequestImage packet is used to request different quality levels (not different texture sizes as the protocol documentation states, SL uses LRCP ordered JPEG2000 files), but i can't figure out what the values correspond to. In a typical texture download I'll see values ranging from -1 to 5. Is -1 a special value? Is there an upper limit? Does a larger number mean a lower quality layer? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080918/1d1f2068/attachment.htm From darien.caldwell at gmail.com Thu Sep 18 13:09:55 2008 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Thu Sep 18 13:09:58 2008 Subject: [sldev] Curious about latest trunk update/LLSD changes/InventoryService In-Reply-To: <48D222D1.9030103@lindenlab.com> References: <9bb32d430809180107h49166c18sd65f12d546910ac4@mail.gmail.com> <48D222D1.9030103@lindenlab.com> Message-ID: <835a5b860809181309t374aaf97x10860fe036221ff8@mail.gmail.com> //DEV-17797. get null folder. Any items found here moved to Lost and Found 2248 LLInventoryModel::findLostItems(); I assume this is the beginning of the fix for the 'no parent folder' issue alluded to in this blog post: http://status.secondlifegrid.net/2008/07/24/post172/ All fine and good, but why isn't the viewer bug which causes this in the first place being fixed? It's 100% reproducible and solving one of the sources of the problem seems more logical than treating the symptoms... http://jira.secondlife.com/browse/VWR-6110?focusedCommentId=60562#action_60562 From secondloop at gmail.com Thu Sep 18 15:15:43 2008 From: secondloop at gmail.com (azdel slade) Date: Thu Sep 18 15:15:47 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D17F32.9000903@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> Message-ID: <1e0ce1090809181515i6b4309d2l7d6f303d7ff84eae@mail.gmail.com> Hi. We're still working on this. One of the developers I'm working with has experience writing opengl code and he ported the patch to the maint-render-8 branch, but he was using a mac and didn't have a build environment so for now all we know is that logically the code should work, but we're working on building it. I should have more info in the next few days. We're focusing on active stereo for use with an hmd like the emagin z800 (the one we're currently working with), not anaglyph. azdel slade On Wed, Sep 17, 2008 at 3:05 PM, Brad Kittenbrink (Brad Linden) wrote: > Bruce Tong wrote: >> >> I found this article on Slashdot. I refers to Nvidia 3D Goggles. Will >> this kind of thing be an option for SL? Graphical issues aren't my >> strong suit, so I thought I'd see what y'all had to say. According to >> the FAQ, there's DirectX support now, OpenGL promised later. Would >> there be other issues? >> >> >> http://www.maximumpc.com/article/features/everything_you_need_know_about_nvidia%E2%80%99s_3d_goggle_gamble?page=0%2C0 >> >> Reference: >> http://tech.slashdot.org/tech/08/09/17/1530202.shtml >> >> > > Work on a stereoscopic rendering patch for the viewer has been going on > under https://jira.secondlife.com/browse/VWR-2972 but I haven't been doing a > good job of keeping track of progress lately. > > The focus has been mostly on anaglyph stereo rendering, but it could > possibly be adapted to other stereo displays. > > The main issue is that after impostors were introduced, we've been using a > bunch of render to texture all over the place, so dropping in stereo won't > 'just work' in current viewers. A problem that will only get worse if/when > the shadow-draft branch gets beyond the draft stage. > > The patch as written against 1.18.2.1 would likely apply relatively cleanly > to 1.19.0.x series viewers. So those might work with the nVidia goggles > when they release OpenGL support. > > -Brad > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From robin.cornelius at gmail.com Thu Sep 18 15:30:08 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Sep 18 15:30:29 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: References: Message-ID: <48D2D670.3060804@gmail.com> John Hurliman wrote: > I know that the DiscardLevel field in the RequestImage packet is used to > request different quality levels (not different texture sizes as the > protocol documentation states, SL uses LRCP ordered JPEG2000 files), but > i can't figure out what the values correspond to. In a typical texture > download I'll see values ranging from -1 to 5. Is -1 a special value? Is > there an upper limit? Does a larger number mean a lower quality layer? > Hey John, The discard field is directly related to the request quality level as you are already aware. It should be a simple calculation that the discard is the number of powers of 2 to scale the image down by for the reduced quality. So a discard of 0 is the complete image and a discard of 1 is a 1/2 size, a discard of 2 is a 1/4 size etc. The wiki confusion probably comes from the fact the texture console displays the scaled down size, so a discard of 4 on a 512x512 texture is displaying as a 64x64 on the texture console until it gets enough data to cross to a better discard level then the texture console will update to show the last successful decoded threshold. The -1 is used to cancel a request image and also seems to be the default initialiser for most of the internal discard fields. The range of the data is kind of predetermined for SL by the values set in the encoder used for image upload. I guess you could upload textures with different discards but i believe we have been around this loop before with early implementations of openjpeg which did it differently to KDU and caused various image breakage. Also we know until recently the viewer was making hideous assumptions about the data length of a given discard level and guessing how much data would be present (top corner jobs), i believe the server is still doing this and thats why some textures take a long time to download although things do seem much much better so maybe this has been addressed as well. Well thats what i know from having my head stuck in the texture pipeline ;-) Hope its helpful Robin/MichelleZ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080918/3becd16e/signature.pgp From secret.argent at gmail.com Thu Sep 18 16:14:51 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Sep 18 16:14:56 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> Message-ID: <4D2EDBA0-653F-4CB0-8234-B54EB079CC37@gmail.com> On 2008-09-18, at 10:23, Dahlia Trimble wrote: > On Thu, Sep 18, 2008 at 8:17 AM, Lawson English > wrote: >> Seriously, with capability-based data transfer, it should be >> possible to request optional streams of data for specialized >> viewers that support these optional streams (e.g. different camera >> view), just as limited clients will be able to NOT receive >> specific data streams as the OGP matures and is incorporated into >> the SL main grid. > Sounds to me like it's something that would be implemented entirely > client side Nod. I don't see why either of these would need any server-side work, nor what OGP would have to do with it. The former was almost possible in First Look 57575 using a reflective HUD (completely non-scripted, the 'rear view' was done entirely in the viewer), and the latter would be a user-interface element for the binocular client (Advanced- >Character->head size ^^ (or maybe ^_^ or ^__^)). From davep at lindenlab.com Fri Sep 19 13:04:29 2008 From: davep at lindenlab.com (David Parks) Date: Fri Sep 19 13:04:31 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> Message-ID: <48D405CD.7080703@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/4f22771d/attachment.htm From philip at lindenlab.com Fri Sep 19 13:23:19 2008 From: philip at lindenlab.com (Philip Rosedale) Date: Fri Sep 19 13:23:57 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D405CD.7080703@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> Message-ID: <48D40A37.9040302@lindenlab.com> I remain skeptical that people will ever want to suffer a large performance cost in visual acuity or frame rate for the benefit delivered from binocular disparity. I think that using a camera to detect eyepoint and shifting the view frustrum in the manner demonstrated by Johnny Chung Lee with his Wii experiments is probably a more compelling way of enhancing the sense of depth, and this approach imposes no additional rendering costs. While some people are not even sensitive to the information conveyed by a stereo pair, everyone can clearly see the effects of properly moving the eyepoint. Philip David Parks wrote: > >From reading an interview about the technology, it sounds like NVIDIA > is revisiting their old method of implementing the stereoscopic effect > in the driver. They did this several years ago, but it was > ill-timed. The shutter glasses require 120hz displays, and at the > time they tried to market this originally, 120hz CRTs were common, but > then everyone switched to 60hz LCD with 16ms response times. Now > 120hz LCDs are flooding the market, so it's time to try again. > > > The old method relied on depth buffer post-processing, so screen space > effects were a no-no and there were always ugly artifacts around > silhouettes. It sounds like the new method actually runs through the > command buffer twice, generating two entirely separate images. Time > will tell how well it interacts with multiple render targets and > deferred rendering. Since this is implemented in the driver, there's > not much we can do about making impostors play nice. They'd basically > look like cardboard cut outs in the background. If someone is > enabling stereo display, though, they've probably got a pretty intense > rig, so turning impostors off is an option. > > > Dale Mahalko wrote: >> While I have not looked at the code for render-to-texture, it sounds >> to me like it could be fairly easily updated to work properly with >> stereoscopic viewers. The code just needs to run a second time to make >> stereoscopic image pairs with depth perception. >> >> Rather than making one "impostor in the middle" as for the current >> single-eye viewer that offers no depth perception, it would make two >> impostors, each rendered slightly offset to the left and right of the >> center camera view and aligning with the stereo viewer's eye >> separation distance. >> >> - Dale >> >> >> On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) >> wrote: >> >>> The main issue is that after impostors were introduced, we've been using a >>> bunch of render to texture all over the place, so dropping in stereo won't >>> 'just work' in current viewers. A problem that will only get worse if/when >>> the shadow-draft branch gets beyond the draft stage. >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/8d809f17/attachment.htm From lenglish5 at cox.net Fri Sep 19 13:52:57 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 19 13:53:00 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> Message-ID: <48D41129.2060404@cox.net> Dahlia Trimble wrote: > > > On Thu, Sep 18, 2008 at 8:17 AM, Lawson English > wrote: > > Argent Stonecutter wrote: > > > > > 2. You know what would be cool for 3d? A control to > dynamically adjust the 3d separation, like the current "zoom" > control. Yes, it's not realistic, who cares? It's virtual. > > See above. > > > Seriously, with capability-based data transfer, it should be > possible to request optional streams of data for specialized > viewers that support these optional streams (e.g. different camera > view), just as limited clients will be able to NOT receive > specific data streams as the OGP matures and is incorporated into > the SL main grid. > > > Sounds to me like it's something that would be implemented entirely > client side Can you generate a different camera view clientside that will contain all the relevant info? Lawson From lenglish5 at cox.net Fri Sep 19 14:03:37 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 19 14:03:40 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D41129.2060404@cox.net> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> <48D41129.2060404@cox.net> Message-ID: <48D413A9.1050703@cox.net> Lawson English wrote: > Dahlia Trimble wrote: >> >> >> On Thu, Sep 18, 2008 at 8:17 AM, Lawson English > > wrote: >> >> Argent Stonecutter wrote: >> >> >> >> >> 2. You know what would be cool for 3d? A control to >> dynamically adjust the 3d separation, like the current "zoom" >> control. Yes, it's not realistic, who cares? It's virtual. >> >> See above. >> >> >> Seriously, with capability-based data transfer, it should be >> possible to request optional streams of data for specialized >> viewers that support these optional streams (e.g. different camera >> view), just as limited clients will be able to NOT receive >> specific data streams as the OGP matures and is incorporated into >> the SL main grid. >> >> >> Sounds to me like it's something that would be implemented entirely >> client side > Can you generate a different camera view clientside that will contain > all the relevant info? > > Nevermind, answered that question myself: of course you can given only a few inches difference in perspective. Lawson From noahwoori at gmail.com Fri Sep 19 14:08:35 2008 From: noahwoori at gmail.com (Noah Woori) Date: Fri Sep 19 14:08:37 2008 Subject: [sldev] First Time Build - Need Help Message-ID: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> Hello everyone, this is my first time to build the Viewer for WinXP Pro using Visual Studio 2005 Pro. After some time I finally was able to acheave success using CMake and made it through the >>Develop.PY -G VC80 Build Viewer from the command prompt. Yeah!!!! Now I have another problem when I try to execute the SecondLife-Bin.Exe i first had a runtime error where i needed to copy the FMod.DLL to the relwithdebinfo directory. Now I am getting the error message: "ERROR: LLImageGL::createGLTexture:LLImageGL::createGLTexture failed to make texture" Now what?????? I would very much like to see my first build succeed. Please help anyone, Thanks. --Noah. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/88fb3d26/attachment.htm From lenglish5 at cox.net Fri Sep 19 14:01:12 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 19 14:10:02 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <4D2EDBA0-653F-4CB0-8234-B54EB079CC37@gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> <4D2EDBA0-653F-4CB0-8234-B54EB079CC37@gmail.com> Message-ID: <48D41318.9010802@cox.net> Argent Stonecutter wrote: > On 2008-09-18, at 10:23, Dahlia Trimble wrote: >> On Thu, Sep 18, 2008 at 8:17 AM, Lawson English >> wrote: >>> Seriously, with capability-based data transfer, it should be >>> possible to request optional streams of data for specialized viewers >>> that support these optional streams (e.g. different camera view), >>> just as limited clients will be able to NOT receive specific data >>> streams as the OGP matures and is incorporated into the SL main grid. > >> Sounds to me like it's something that would be implemented entirely >> client side > > Nod. > > I don't see why either of these would need any server-side work, nor > what OGP would have to do with it. The former was almost possible in > First Look 57575 using a reflective HUD (completely non-scripted, the > 'rear view' was done entirely in the viewer), and the latter would be > a user-interface element for the binocular client > (Advanced->Character->head size ^^ (or maybe ^_^ or ^__^)). > > well, I wasn't thinking very well concerning the camera view since a 3-4" difference in perspective doesn't require any change in scene graph info. As far as OGP is concerned, same deal. If you can generate the proper geometry for the second perspective from the info the client currently gets, you obviously don't need to ask for more info from the server. Though, it is something to keep in mind anyway: would a separate pipeline for rendering info make things more efficient generically, not just for stereoscopic glasses? They are already experimenting with sending textures via their own cap. Would sending other info separately make more sense as well? Lawson From timelessprototype at gmail.com Fri Sep 19 14:11:07 2008 From: timelessprototype at gmail.com (Timeless Prototype) Date: Fri Sep 19 14:11:12 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D40A37.9040302@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> Message-ID: <48D4156B.10501@gmail.com> A valid point for a single person viewing interactively (Johnny Chung method), but perhaps not so much for an audience of non-interacting viewers (anaglyph/shutter) or still-"life" snapshots to be viewed later in print/web (anaglyph/sterogram/etc). Throw them all in and let the people/businesses/.edu's choose and buy appropriate equipment to match if they want these features. I personally would suffer some FPS for the occasional enhanced immersion. Nice stuff. :) - Timeless Philip Rosedale wrote: > I remain skeptical that people will ever want to suffer a large > performance cost in visual acuity or frame rate for the benefit > delivered from binocular disparity. I think that using a camera to > detect eyepoint and shifting the view frustrum in the manner > demonstrated by Johnny Chung Lee with his Wii experiments is probably a > more compelling way of enhancing the sense of depth, and this approach > imposes no additional rendering costs. While some people are not even > sensitive to the information conveyed by a stereo pair, everyone can > clearly see the effects of properly moving the eyepoint. > > Philip > > David Parks wrote: >> >From reading an interview about the technology, it sounds like NVIDIA >> is revisiting their old method of implementing the stereoscopic effect >> in the driver. They did this several years ago, but it was >> ill-timed. The shutter glasses require 120hz displays, and at the >> time they tried to market this originally, 120hz CRTs were common, but >> then everyone switched to 60hz LCD with 16ms response times. Now >> 120hz LCDs are flooding the market, so it's time to try again. >> >> >> The old method relied on depth buffer post-processing, so screen space >> effects were a no-no and there were always ugly artifacts around >> silhouettes. It sounds like the new method actually runs through the >> command buffer twice, generating two entirely separate images. Time >> will tell how well it interacts with multiple render targets and >> deferred rendering. Since this is implemented in the driver, there's >> not much we can do about making impostors play nice. They'd basically >> look like cardboard cut outs in the background. If someone is >> enabling stereo display, though, they've probably got a pretty intense >> rig, so turning impostors off is an option. >> >> >> Dale Mahalko wrote: >>> While I have not looked at the code for render-to-texture, it sounds >>> to me like it could be fairly easily updated to work properly with >>> stereoscopic viewers. The code just needs to run a second time to make >>> stereoscopic image pairs with depth perception. >>> >>> Rather than making one "impostor in the middle" as for the current >>> single-eye viewer that offers no depth perception, it would make two >>> impostors, each rendered slightly offset to the left and right of the >>> center camera view and aligning with the stereo viewer's eye >>> separation distance. >>> >>> - Dale >>> >>> >>> On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) >>> wrote: >>> >>>> The main issue is that after impostors were introduced, we've been using a >>>> bunch of render to texture all over the place, so dropping in stereo won't >>>> 'just work' in current viewers. A problem that will only get worse if/when >>>> the shadow-draft branch gets beyond the draft stage. >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From gareth at litesim.com Fri Sep 19 14:17:41 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Sep 19 14:17:43 2008 Subject: [sldev] First Time Build - Need Help In-Reply-To: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> References: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> Message-ID: <61dbdd7d0809191417i17bb9b64je9940bee5fbbc11e@mail.gmail.com> This is a known issue I believe, related to issues with the viewer manifest? On Fri, Sep 19, 2008 at 10:08 PM, Noah Woori wrote: > Hello everyone, this is my first time to build the Viewer for WinXP Pro > using Visual Studio 2005 Pro. After some time I finally was able to acheave > success using CMake and made it through the >>Develop.PY -G VC80 Build > Viewer from the command prompt. Yeah!!!! > > Now I have another problem when I try to execute the SecondLife-Bin.Exe i > first had a runtime error where i needed to copy the FMod.DLL to the > relwithdebinfo directory. Now I am getting the error message: "ERROR: > LLImageGL::createGLTexture:LLImageGL::createGLTexture failed to make > texture" > > Now what?????? I would very much like to see my first build succeed. Please > help anyone, Thanks. > > --Noah. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From dahliatrimble at gmail.com Fri Sep 19 14:21:10 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Sep 19 14:21:12 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D41129.2060404@cox.net> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> <48D41129.2060404@cox.net> Message-ID: Linden's servers do maintain some kind of "interest list" that uses camera position to decide what content to send to the viewer, but the client usually has control of the position anyway. I don't think small changes in camera focus direction affect it much, but large changes such as turning your avatar 180 degrees will result in a lot of object create and kill packets being sent to your viewer. Opensim currently sends the whole region to each viewer so it wouldn't be an issue. Still, this behavior would seem to work the same way as it does with the current viewers unless the camera separation was taken to some extreme. On Fri, Sep 19, 2008 at 1:52 PM, Lawson English wrote: > Dahlia Trimble wrote: > > >> >> On Thu, Sep 18, 2008 at 8:17 AM, Lawson English > lenglish5@cox.net>> wrote: >> >> Argent Stonecutter wrote: >> >> >> >> >> 2. You know what would be cool for 3d? A control to >> dynamically adjust the 3d separation, like the current "zoom" >> control. Yes, it's not realistic, who cares? It's virtual. >> >> See above. >> >> >> Seriously, with capability-based data transfer, it should be >> possible to request optional streams of data for specialized >> viewers that support these optional streams (e.g. different camera >> view), just as limited clients will be able to NOT receive >> specific data streams as the OGP matures and is incorporated into >> the SL main grid. >> >> >> Sounds to me like it's something that would be implemented entirely client >> side >> > Can you generate a different camera view clientside that will contain all > the relevant info? > > > Lawson > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/63f004d9/attachment.htm From gareth at litesim.com Fri Sep 19 14:22:23 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Sep 19 14:22:35 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D40A37.9040302@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> Message-ID: <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> Wow, the man himself :) The absolute ideal way to do 3D would be to have 2 displays on seperate LCD panels mounted in an HMD - more fiddly to setup (dual video cards required most likely) but would be VERY immersive if you could also get hold of an eyetracker. Whatever happened to the rig anyway? On Fri, Sep 19, 2008 at 9:23 PM, Philip Rosedale wrote: > I remain skeptical that people will ever want to suffer a large performance > cost in visual acuity or frame rate for the benefit delivered from binocular > disparity. I think that using a camera to detect eyepoint and shifting the > view frustrum in the manner demonstrated by Johnny Chung Lee with his Wii > experiments is probably a more compelling way of enhancing the sense of > depth, and this approach imposes no additional rendering costs. While some > people are not even sensitive to the information conveyed by a stereo pair, > everyone can clearly see the effects of properly moving the eyepoint. > > Philip > > David Parks wrote: > > >From reading an interview about the technology, it sounds like NVIDIA is > revisiting their old method of implementing the stereoscopic effect in the > driver. They did this several years ago, but it was ill-timed. The shutter > glasses require 120hz displays, and at the time they tried to market this > originally, 120hz CRTs were common, but then everyone switched to 60hz LCD > with 16ms response times. Now 120hz LCDs are flooding the market, so it's > time to try again. > > > The old method relied on depth buffer post-processing, so screen space > effects were a no-no and there were always ugly artifacts around > silhouettes. It sounds like the new method actually runs through the > command buffer twice, generating two entirely separate images. Time will > tell how well it interacts with multiple render targets and deferred > rendering. Since this is implemented in the driver, there's not much we can > do about making impostors play nice. They'd basically look like cardboard > cut outs in the background. If someone is enabling stereo display, though, > they've probably got a pretty intense rig, so turning impostors off is an > option. > > > Dale Mahalko wrote: > > While I have not looked at the code for render-to-texture, it sounds > to me like it could be fairly easily updated to work properly with > stereoscopic viewers. The code just needs to run a second time to make > stereoscopic image pairs with depth perception. > > Rather than making one "impostor in the middle" as for the current > single-eye viewer that offers no depth perception, it would make two > impostors, each rendered slightly offset to the left and right of the > center camera view and aligning with the stereo viewer's eye > separation distance. > > - Dale > > > On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) > wrote: > > > The main issue is that after impostors were introduced, we've been using a > bunch of render to texture all over the place, so dropping in stereo won't > 'just work' in current viewers. A problem that will only get worse if/when > the shadow-draft branch gets beyond the draft stage. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > ________________________________ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From lenglish5 at cox.net Fri Sep 19 14:23:49 2008 From: lenglish5 at cox.net (Lawson English) Date: Fri Sep 19 14:23:52 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D4156B.10501@gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> <48D4156B.10501@gmail.com> Message-ID: <48D41865.2070401@cox.net> Timeless Prototype wrote: > A valid point for a single person viewing interactively (Johnny Chung > method), but perhaps not so much for an audience of non-interacting > viewers (anaglyph/shutter) or still-"life" snapshots to be viewed later > in print/web (anaglyph/sterogram/etc). > > Throw them all in and let the people/businesses/.edu's choose and buy > appropriate equipment to match if they want these features. I personally > would suffer some FPS for the occasional enhanced immersion. Nice stuff. :) > > - Timeless > At that point having separate pipelines for various parts of the rendering info makes sense because you could run rendering in seperate processes on seperate hardware dedicated just to that task, for, say, broadcast to smartphones or the web, and that is where OGP would come into play (what I had been thinking of while pontificating about OGP for no reason concerning stereo glasses). You could also request ultra-highend rendering info designed for your ultra-highend rendering hardware, that wouldn't normally be sent to the average client but might make sense for mechanima productions, maybe with high end lipsynch data or more refined avatar movement or etc. Lawson > Philip Rosedale wrote: > >> I remain skeptical that people will ever want to suffer a large >> performance cost in visual acuity or frame rate for the benefit >> delivered from binocular disparity. I think that using a camera to >> detect eyepoint and shifting the view frustrum in the manner >> demonstrated by Johnny Chung Lee with his Wii experiments is probably a >> more compelling way of enhancing the sense of depth, and this approach >> imposes no additional rendering costs. While some people are not even >> sensitive to the information conveyed by a stereo pair, everyone can >> clearly see the effects of properly moving the eyepoint. >> >> Philip >> >> David Parks wrote: >> >>> >From reading an interview about the technology, it sounds like NVIDIA >>> is revisiting their old method of implementing the stereoscopic effect >>> in the driver. They did this several years ago, but it was >>> ill-timed. The shutter glasses require 120hz displays, and at the >>> time they tried to market this originally, 120hz CRTs were common, but >>> then everyone switched to 60hz LCD with 16ms response times. Now >>> 120hz LCDs are flooding the market, so it's time to try again. >>> >>> >>> The old method relied on depth buffer post-processing, so screen space >>> effects were a no-no and there were always ugly artifacts around >>> silhouettes. It sounds like the new method actually runs through the >>> command buffer twice, generating two entirely separate images. Time >>> will tell how well it interacts with multiple render targets and >>> deferred rendering. Since this is implemented in the driver, there's >>> not much we can do about making impostors play nice. They'd basically >>> look like cardboard cut outs in the background. If someone is >>> enabling stereo display, though, they've probably got a pretty intense >>> rig, so turning impostors off is an option. >>> >>> >>> Dale Mahalko wrote: >>> >>>> While I have not looked at the code for render-to-texture, it sounds >>>> to me like it could be fairly easily updated to work properly with >>>> stereoscopic viewers. The code just needs to run a second time to make >>>> stereoscopic image pairs with depth perception. >>>> >>>> Rather than making one "impostor in the middle" as for the current >>>> single-eye viewer that offers no depth perception, it would make two >>>> impostors, each rendered slightly offset to the left and right of the >>>> center camera view and aligning with the stereo viewer's eye >>>> separation distance. >>>> >>>> - Dale >>>> >>>> >>>> On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) >>>> wrote: >>>> >>>> >>>>> The main issue is that after impostors were introduced, we've been using a >>>>> bunch of render to texture all over the place, so dropping in stereo won't >>>>> 'just work' in current viewers. A problem that will only get worse if/when >>>>> the shadow-draft branch gets beyond the draft stage. >>>>> >>>>> >>>> _______________________________________________ >>>> Policies and (un)subscribe information available here: >>>> http://wiki.secondlife.com/wiki/SLDev >>>> Please read the policies before posting to keep unmoderated posting privileges >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dahliatrimble at gmail.com Fri Sep 19 14:36:45 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Fri Sep 19 14:36:48 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> Message-ID: By "HMD" do you mean Head Mounted Display? I doubt that many people could focus on something close to their eyes without some kind of special lenses between their eyes and the screens. If it wouldn't work with normal vision or with glasses, it could severely limit the available market. On Fri, Sep 19, 2008 at 2:22 PM, Gareth Nelson wrote: > Wow, the man himself :) > The absolute ideal way to do 3D would be to have 2 displays on > seperate LCD panels mounted in an HMD - more fiddly to setup (dual > video cards required most likely) but would be VERY immersive if you > could also get hold of an eyetracker. > > Whatever happened to the rig anyway? > > On Fri, Sep 19, 2008 at 9:23 PM, Philip Rosedale > wrote: > > I remain skeptical that people will ever want to suffer a large > performance > > cost in visual acuity or frame rate for the benefit delivered from > binocular > > disparity. I think that using a camera to detect eyepoint and shifting > the > > view frustrum in the manner demonstrated by Johnny Chung Lee with his Wii > > experiments is probably a more compelling way of enhancing the sense of > > depth, and this approach imposes no additional rendering costs. While > some > > people are not even sensitive to the information conveyed by a stereo > pair, > > everyone can clearly see the effects of properly moving the eyepoint. > > > > Philip > > > > David Parks wrote: > > > > >From reading an interview about the technology, it sounds like NVIDIA is > > revisiting their old method of implementing the stereoscopic effect in > the > > driver. They did this several years ago, but it was ill-timed. The > shutter > > glasses require 120hz displays, and at the time they tried to market this > > originally, 120hz CRTs were common, but then everyone switched to 60hz > LCD > > with 16ms response times. Now 120hz LCDs are flooding the market, so > it's > > time to try again. > > > > > > The old method relied on depth buffer post-processing, so screen space > > effects were a no-no and there were always ugly artifacts around > > silhouettes. It sounds like the new method actually runs through the > > command buffer twice, generating two entirely separate images. Time will > > tell how well it interacts with multiple render targets and deferred > > rendering. Since this is implemented in the driver, there's not much we > can > > do about making impostors play nice. They'd basically look like > cardboard > > cut outs in the background. If someone is enabling stereo display, > though, > > they've probably got a pretty intense rig, so turning impostors off is an > > option. > > > > > > Dale Mahalko wrote: > > > > While I have not looked at the code for render-to-texture, it sounds > > to me like it could be fairly easily updated to work properly with > > stereoscopic viewers. The code just needs to run a second time to make > > stereoscopic image pairs with depth perception. > > > > Rather than making one "impostor in the middle" as for the current > > single-eye viewer that offers no depth perception, it would make two > > impostors, each rendered slightly offset to the left and right of the > > center camera view and aligning with the stereo viewer's eye > > separation distance. > > > > - Dale > > > > > > On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) > > wrote: > > > > > > The main issue is that after impostors were introduced, we've been using > a > > bunch of render to texture all over the place, so dropping in stereo > won't > > 'just work' in current viewers. A problem that will only get worse > if/when > > the shadow-draft branch gets beyond the draft stage. > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > > > ________________________________ > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/3fd1eab4/attachment-0001.htm From gareth at litesim.com Fri Sep 19 14:39:59 2008 From: gareth at litesim.com (Gareth Nelson) Date: Fri Sep 19 14:40:06 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> Message-ID: <61dbdd7d0809191439o75e5662ua792800dedaab3c9@mail.gmail.com> I have an HMD at home, a rather cheap one but i've used it in SL before with great results (rather freaky in fact just how immersive it was). It would be even greater if it was a stereo unit, and as it so happens there's already HMDs on the market that do precisely what i'm describing here. On Fri, Sep 19, 2008 at 10:36 PM, Dahlia Trimble wrote: > By "HMD" do you mean Head Mounted Display? I doubt that many people could > focus on something close to their eyes without some kind of special lenses > between their eyes and the screens. If it wouldn't work with normal vision > or with glasses, it could severely limit the available market. > > On Fri, Sep 19, 2008 at 2:22 PM, Gareth Nelson wrote: >> >> Wow, the man himself :) >> The absolute ideal way to do 3D would be to have 2 displays on >> seperate LCD panels mounted in an HMD - more fiddly to setup (dual >> video cards required most likely) but would be VERY immersive if you >> could also get hold of an eyetracker. >> >> Whatever happened to the rig anyway? >> >> On Fri, Sep 19, 2008 at 9:23 PM, Philip Rosedale >> wrote: >> > I remain skeptical that people will ever want to suffer a large >> > performance >> > cost in visual acuity or frame rate for the benefit delivered from >> > binocular >> > disparity. I think that using a camera to detect eyepoint and shifting >> > the >> > view frustrum in the manner demonstrated by Johnny Chung Lee with his >> > Wii >> > experiments is probably a more compelling way of enhancing the sense of >> > depth, and this approach imposes no additional rendering costs. While >> > some >> > people are not even sensitive to the information conveyed by a stereo >> > pair, >> > everyone can clearly see the effects of properly moving the eyepoint. >> > >> > Philip >> > >> > David Parks wrote: >> > >> > >From reading an interview about the technology, it sounds like NVIDIA >> > is >> > revisiting their old method of implementing the stereoscopic effect in >> > the >> > driver. They did this several years ago, but it was ill-timed. The >> > shutter >> > glasses require 120hz displays, and at the time they tried to market >> > this >> > originally, 120hz CRTs were common, but then everyone switched to 60hz >> > LCD >> > with 16ms response times. Now 120hz LCDs are flooding the market, so >> > it's >> > time to try again. >> > >> > >> > The old method relied on depth buffer post-processing, so screen space >> > effects were a no-no and there were always ugly artifacts around >> > silhouettes. It sounds like the new method actually runs through the >> > command buffer twice, generating two entirely separate images. Time >> > will >> > tell how well it interacts with multiple render targets and deferred >> > rendering. Since this is implemented in the driver, there's not much we >> > can >> > do about making impostors play nice. They'd basically look like >> > cardboard >> > cut outs in the background. If someone is enabling stereo display, >> > though, >> > they've probably got a pretty intense rig, so turning impostors off is >> > an >> > option. >> > >> > >> > Dale Mahalko wrote: >> > >> > While I have not looked at the code for render-to-texture, it sounds >> > to me like it could be fairly easily updated to work properly with >> > stereoscopic viewers. The code just needs to run a second time to make >> > stereoscopic image pairs with depth perception. >> > >> > Rather than making one "impostor in the middle" as for the current >> > single-eye viewer that offers no depth perception, it would make two >> > impostors, each rendered slightly offset to the left and right of the >> > center camera view and aligning with the stereo viewer's eye >> > separation distance. >> > >> > - Dale >> > >> > >> > On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) >> > wrote: >> > >> > >> > The main issue is that after impostors were introduced, we've been using >> > a >> > bunch of render to texture all over the place, so dropping in stereo >> > won't >> > 'just work' in current viewers. A problem that will only get worse >> > if/when >> > the shadow-draft branch gets beyond the draft stage. >> > >> > >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> > >> > ________________________________ >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> > _______________________________________________ >> > Policies and (un)subscribe information available here: >> > http://wiki.secondlife.com/wiki/SLDev >> > Please read the policies before posting to keep unmoderated posting >> > privileges >> > >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From secret.argent at gmail.com Fri Sep 19 15:18:35 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Sep 19 15:18:40 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <66E8C9BC-8D2B-4B13-90D5-F5779A49404A@gmail.com> <48D2710E.1020901@cox.net> <48D41129.2060404@cox.net> Message-ID: <0C0086CA-A10E-4F0A-944C-27D9CB26CA72@gmail.com> On 2008-09-19, at 16:21, Dahlia Trimble wrote: > Linden's servers do maintain some kind of "interest list" that uses > camera position to decide what content to send to the viewer, but > the client usually has control of the position anyway. The interest list is also less effected by the camera position than it should be, since it's not ordered by distance from the camera, but by the sim object ID, which is monotonically increasing so in practice objects show up in rez order. This is rarely what you want. :) I don't think turning the camera 180 degrees causes the server to send object delete requests, or else you'd see objects vanishing from the mini-map as you turn around. Also, if you have RenderDynamicReflections turned on you need to have stuff behind you rendered to get the reflection cube updated correctly. Even with RenderDynamicReflections as nerfed as it is these days. From Celierra at gmail.com Fri Sep 19 15:24:10 2008 From: Celierra at gmail.com (Celierra Darling) Date: Fri Sep 19 15:24:13 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D40A37.9040302@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> <48D40A37.9040302@lindenlab.com> Message-ID: I've been thinking about this. I think that the method with the smallest barrier to entry is via a webcam and detecting eyes in its images. A quick search turns up 2004 D'Orazio, "An Algorithm for Real Time Eye Detection in Face Images" [1]. They used 640x480 images, and with a paltry Pentium 3 CPU, they report 300 ms per image. I have to assume a modern GPU implementation should be much faster, and the 300ms is without context between images; perhaps a Kalman filter[2] would be nice to narrow the search? Then the only things needed from the user are, I think, the physical screen size, and a calibration picture with the person a known distance away (to figure out the webcam's field of view). One thing I'm wondering about: if I understand it right, Johnny Lee's solution *should* make things look as if the monitor were a window into SL. But the placement of the monitor could be problematic - the view might end up seeming awfully small if the person's far away from the monitor. (Personally, my vertical field of view would be just 16 degrees, and 24.8 degrees horizontally.) I wonder if this would be okay? Would scaling up/down the head movement be better, or would it become more unnatural? [1] http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1334521 [2] http://en.wikipedia.org/wiki/Kalman_filter#Example ~Celi On Fri, Sep 19, 2008 at 4:23 PM, Philip Rosedale wrote: > I remain skeptical that people will ever want to suffer a large performance > cost in visual acuity or frame rate for the benefit delivered from binocular > disparity. I think that using a camera to detect eyepoint and shifting the > view frustrum in the manner demonstrated by Johnny Chung Lee with his Wii > experiments is probably a more compelling way of enhancing the sense of > depth, and this approach imposes no additional rendering costs. While some > people are not even sensitive to the information conveyed by a stereo pair, > everyone can clearly see the effects of properly moving the eyepoint. > > Philip > From noahwoori at gmail.com Fri Sep 19 15:33:26 2008 From: noahwoori at gmail.com (Noah Woori) Date: Fri Sep 19 15:33:29 2008 Subject: [sldev] Re: First Time Build - Need Help In-Reply-To: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> References: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> Message-ID: <252e92d70809191533t4c4ae035v38419c4e220369ac@mail.gmail.com> still looking for answers, I have searched the wiki to no avail. I am going into debug now. Anyone out there in SLDev land? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080919/8bf33207/attachment.htm From carjay at gmx.net Fri Sep 19 15:45:02 2008 From: carjay at gmx.net (Carsten Juttner) Date: Fri Sep 19 15:45:16 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: <48D2D670.3060804@gmail.com> References: <48D2D670.3060804@gmail.com> Message-ID: <48D42B6E.1070903@gmx.net> Robin Cornelius wrote: > John Hurliman wrote: > >> I know that the DiscardLevel field in the RequestImage packet is used to >> request different quality levels (not different texture sizes as the >> protocol documentation states, SL uses LRCP ordered JPEG2000 files), but >> i can't figure out what the values correspond to. In a typical texture >> download I'll see values ranging from -1 to 5. Is -1 a special value? Is >> there an upper limit? Does a larger number mean a lower quality layer? >> >> > > The discard field is directly related to the request quality level as > you are already aware. It should be a simple calculation that the > discard is the number of powers of 2 to scale the image down by for the > reduced quality. So a discard of 0 is the complete image and a discard > of 1 is a 1/2 size, a discard of 2 is a 1/4 size etc. > I think what John was actually referring to here is that quality layers and resolution levels are not the same. In JPEG2k all data is divided into packets for one tile. Each packet contains codestream data for one quality layer for one resolution for one component for one precinct (spatial partition). The order in which you transmit the packets decides what you get first and is signalled by the "progression order". LRCP (Layer-Resolution-Component-Position) is layer-centric meaning that one by one you get all the data for each quality layer, not for each resolution. That means you end up with the lowest quality layer for all resolutions first so it's really a quality-based progression, not a resolution-based. Think of the quality layers as going down the bits from MSB to LSB. First you get the rough information, then it progresses to the detailed information (actually for the wavelet coefficients). AFAIK, inside the viewer the progression order is not really cared about and the discard levels are merely referring to the dropped resolutions from the highest resolution. Also nobody seems to really know what is happening on the server side since we did ask a while ago but never met a Linden who was familiar with that area of the code so it's still a bit of a mystery. Regards, Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080920/fc30ffe8/attachment.htm From robla at lindenlab.com Fri Sep 19 15:50:41 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 19 15:50:51 2008 Subject: [sldev] Re: First Time Build - Need Help In-Reply-To: <252e92d70809191533t4c4ae035v38419c4e220369ac@mail.gmail.com> References: <252e92d70809191408o43c6c782rcdb67dfe6e1b4135@mail.gmail.com> <252e92d70809191533t4c4ae035v38419c4e220369ac@mail.gmail.com> Message-ID: <48D42CC1.1070100@lindenlab.com> On 9/19/08 3:33 PM, Noah Woori wrote: > still looking for answers, I have searched the wiki to no avail. I am > going into debug now. Anyone out there in SLDev land? Sorry, I think your message got lost in some of the other threads. > Now I am getting the error message: "ERROR: > LLImageGL::createGLTexture:LLImageGL::createGLTexture failed to make > texture" I'm going to guess that you might not have downloaded the artwork bundle when you compiled. Without knowing which version of the source code you're starting with, I can't give you a direct URL to the right artwork package, but look for the appropriate "Artwork" package on this page: http://wiki.secondlife.com/wiki/Source_downloads If you're still having problems, the #opensl channel on irc.efnet.org is a great place to get real-time help. Rob From sheet.spotter at gmail.com Fri Sep 19 20:22:33 2008 From: sheet.spotter at gmail.com (Sheet Spotter) Date: Fri Sep 19 20:22:42 2008 Subject: [sldev] Alternative to Nvidia 3D Goggles? In-Reply-To: <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com><48D40A37.9040302@lindenlab.com> <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> Message-ID: <6E69FC15CECA4337B8A5EA05876E8A78@kenb> PureDepth Inc. has patented a simple, yet exciting approach to 3D, by creating Multi-Layer Displays. It is essentially two LCD flat panels mounted on top of each other. http://www.puredepth.com/ There is a five minute blurb on YouTube, although the sound is a bit messed up. http://www.youtube.com/watch?v=8UOY4kG_CGA I wish I lived closer to their headquarters...I would love to see one in action, and to learn more about the software/hardware required to drive the multiple layers. (I have no affiliation with either PureDepth or YouTube.) Sheet Spotter -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Gareth Nelson Sent: September 19, 2008 4:22 PM To: Philip Rosedale Cc: Second Life Developer Mailing List Subject: Re: [sldev] Nvidia 3D Goggles? Wow, the man himself :) The absolute ideal way to do 3D would be to have 2 displays on seperate LCD panels mounted in an HMD - more fiddly to setup (dual video cards required most likely) but would be VERY immersive if you could also get hold of an eyetracker. Whatever happened to the rig anyway? On Fri, Sep 19, 2008 at 9:23 PM, Philip Rosedale wrote: > I remain skeptical that people will ever want to suffer a large performance > cost in visual acuity or frame rate for the benefit delivered from binocular > disparity. I think that using a camera to detect eyepoint and shifting the > view frustrum in the manner demonstrated by Johnny Chung Lee with his Wii > experiments is probably a more compelling way of enhancing the sense of > depth, and this approach imposes no additional rendering costs. While some > people are not even sensitive to the information conveyed by a stereo pair, > everyone can clearly see the effects of properly moving the eyepoint. > > Philip > > David Parks wrote: > > >From reading an interview about the technology, it sounds like NVIDIA is > revisiting their old method of implementing the stereoscopic effect in the > driver. They did this several years ago, but it was ill-timed. The shutter > glasses require 120hz displays, and at the time they tried to market this > originally, 120hz CRTs were common, but then everyone switched to 60hz LCD > with 16ms response times. Now 120hz LCDs are flooding the market, so it's > time to try again. > > > The old method relied on depth buffer post-processing, so screen space > effects were a no-no and there were always ugly artifacts around > silhouettes. It sounds like the new method actually runs through the > command buffer twice, generating two entirely separate images. Time will > tell how well it interacts with multiple render targets and deferred > rendering. Since this is implemented in the driver, there's not much we can > do about making impostors play nice. They'd basically look like cardboard > cut outs in the background. If someone is enabling stereo display, though, > they've probably got a pretty intense rig, so turning impostors off is an > option. > > > Dale Mahalko wrote: > > While I have not looked at the code for render-to-texture, it sounds > to me like it could be fairly easily updated to work properly with > stereoscopic viewers. The code just needs to run a second time to make > stereoscopic image pairs with depth perception. > > Rather than making one "impostor in the middle" as for the current > single-eye viewer that offers no depth perception, it would make two > impostors, each rendered slightly offset to the left and right of the > center camera view and aligning with the stereo viewer's eye > separation distance. > > - Dale > > > On Wed, Sep 17, 2008 at 5:05 PM, Brad Kittenbrink (Brad Linden) > wrote: > > > The main issue is that after impostors were introduced, we've been using a > bunch of render to texture all over the place, so dropping in stereo won't > 'just work' in current viewers. A problem that will only get worse if/when > the shadow-draft branch gets beyond the draft stage. > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > ________________________________ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From carjay at gmx.net Sat Sep 20 03:44:13 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sat Sep 20 03:44:15 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <48D405CD.7080703@lindenlab.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com> Message-ID: <48D4D3FD.5050805@gmx.net> David Parks wrote: > The old method relied on depth buffer post-processing, so screen space > effects were a no-no and there were always ugly artifacts around > silhouettes. It sounds like the new method actually runs through the > command buffer twice, generating two entirely separate images. Time > will tell how well it interacts with multiple render targets and > deferred rendering. Since this is implemented in the driver, there's > not much Interesting, I always wondered about the "consumer" stereo. I had to implement a stereoscopic renderer for my thesis (basically a request of my professor) and put a quick hack into the Ogre3D engine so it would support the quad buffer feature of the Quadro series. With this it's a piece of cake, the driver even generates the necessary blue line to drive an external shutter controller. That approach of course cuts the frame rate in half since the renderer was simply executed twice with 2 different projection matrices. I mainly used Paul Bourkes pages for reference but he seems to have rearranged them a bit so my old URL no longer works so one might need to search a bit. His other pages are well worth a visit for any graphics buff anyway. http://local.wasp.uwa.edu.au/~pbourke Regards, Carsten From jan.ciger at gmail.com Sat Sep 20 07:25:48 2008 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat Sep 20 07:25:54 2008 Subject: [sldev] Nvidia 3D Goggles? In-Reply-To: <1e0ce1090809181515i6b4309d2l7d6f303d7ff84eae@mail.gmail.com> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com> <48D17F32.9000903@lindenlab.com> <1e0ce1090809181515i6b4309d2l7d6f303d7ff84eae@mail.gmail.com> Message-ID: <48D507EC.1060209@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 azdel slade wrote: | Hi. We're still working on this. One of the developers I'm working | with has experience writing opengl code and he ported the patch to | the maint-render-8 branch, but he was using a mac and didn't have a | build environment so for now all we know is that logically the code | should work, but we're working on building it. I should have more | info in the next few days. We're focusing on active stereo for use | with an hmd like the emagin z800 (the one we're currently working | with), not anaglyph. | | azdel slade | Azdel, if you need testing, I have a 5x2m stereoscopic wall driven from a Quadro on Linux available. Contact me off-list if you are interested. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFI1Qfsn11XseNj94gRAkNKAKDq2ZjNCLw9hsmGhMfxj8ACTeumpwCgsKkU H9v9j6x2ok1419EejJ/qH/E= =Iylr -----END PGP SIGNATURE----- From aimee at ama-zing.co.uk Sat Sep 20 09:19:31 2008 From: aimee at ama-zing.co.uk (Aimee Walton) Date: Sat Sep 20 09:19:35 2008 Subject: [sldev] Alternative to Nvidia 3D Goggles? In-Reply-To: <6E69FC15CECA4337B8A5EA05876E8A78@kenb> References: <4f335a50809171315p59b57dfav4953c18687934d84@mail.gmail.com><48D17F32.9000903@lindenlab.com> <48D405CD.7080703@lindenlab.com><48D40A37.9040302@lindenlab.com> <61dbdd7d0809191422h30cb806au9f9ddd7b85f2142c@mail.gmail.com> <6E69FC15CECA4337B8A5EA05876E8A78@kenb> Message-ID: On 20 Sep 2008, at 04:22, Sheet Spotter wrote: > > PureDepth Inc. has patented a simple, yet exciting approach to 3D, by > creating Multi-Layer Displays. It is essentially two LCD flat panels > mounted > on top of each other. Hmm, with only two layers that's going to be pretty limited, just a HUD layer and the world view with some depth separation. Even with more layers you're still stuck with a small set of discreet planes with a fixed offset from each other, a bit like flat stage scenery. It also won't be able to occlude properly, you can't have something light coloured in front of something dark. Unless someone takes a massive leap forward in LCD optical transmission efficiency it's going to need some sort of insane nuclear powered backlighting assembly, as LCDs already have horrible optical efficiency, typically around 5%. (I used to work in the design of LCD backlighting systems :) It will probably find some use in arcade machines with a clearly defined foreground and background scene. Or it could make for some interesting user interfaces by popping stuff that needs attention forward out of the background, for safety or time critical stuff in industrial / medical applications. Aimee. From jhurliman at jhurliman.org Sat Sep 20 21:05:40 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sat Sep 20 21:05:44 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: <48D42B6E.1070903@gmx.net> References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> Message-ID: Thank you Carsten, that clarification is correct. For now I'm assuming that DiscardLevel 0 is a request for the full quality (zero discarded levels) and DiscardLevel 5 is requesting the lowest quality level. However, if you start with five quality layers and you discard five of them what are you left with? Is five actually being clamped to four? This still doesn't explain -1. If you send a RequestImage with Priority = 0.0 and DiscardLevel = -1 it will cancel the download, but texture requests often start with a positive priority and a DiscardLevel of -1. Is this a request for the header only, or is it just an uninitialized value in the client that implies zero or four? John On Fri, Sep 19, 2008 at 3:45 PM, Carsten Juttner wrote: > Robin Cornelius wrote: > > John Hurliman wrote: > > > I know that the DiscardLevel field in the RequestImage packet is used to > request different quality levels (not different texture sizes as the > protocol documentation states, SL uses LRCP ordered JPEG2000 files), but > i can't figure out what the values correspond to. In a typical texture > download I'll see values ranging from -1 to 5. Is -1 a special value? Is > there an upper limit? Does a larger number mean a lower quality layer? > > > > The discard field is directly related to the request quality level as > you are already aware. It should be a simple calculation that the > discard is the number of powers of 2 to scale the image down by for the > reduced quality. So a discard of 0 is the complete image and a discard > of 1 is a 1/2 size, a discard of 2 is a 1/4 size etc. > > > > I think what John was actually referring to here is that quality layers and > resolution levels are not the same. In JPEG2k all data is divided into > packets for one tile. Each packet contains codestream data for one quality > layer for one resolution for one component for one precinct (spatial > partition). The order in which you transmit the packets decides what you get > first and is signalled by the "progression order". LRCP > (Layer-Resolution-Component-Position) is layer-centric meaning that one by > one you get all the data for each quality layer, not for each resolution. > That means you end up with the lowest quality layer for all resolutions > first so it's really a quality-based progression, not a resolution-based. > > Think of the quality layers as going down the bits from MSB to LSB. First > you get the rough information, then it progresses to the detailed > information (actually for the wavelet coefficients). > > AFAIK, inside the viewer the progression order is not really cared about > and the discard levels are merely referring to the dropped resolutions from > the highest resolution. > > Also nobody seems to really know what is happening on the server side since > we did ask a while ago but never met a Linden who was familiar with that > area of the code so it's still a bit of a mystery. > > Regards, > Carsten > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080920/87c62fe5/attachment.htm From dooglio at gmail.com Mon Sep 22 01:50:22 2008 From: dooglio at gmail.com (R. Douglas Barbieri) Date: Mon Sep 22 01:50:24 2008 Subject: [sldev] Also first time build...getting "Missing Glyph Info" Message-ID: <367cdf400809220150h2f082aadrd949910985e44ec7@mail.gmail.com> Hi all, I'm new to the SL open source thing, and I am trying to run a trunk build on my AMD64 ubuntu linux box. I managed to get everything to build as standalone using the cmake system, and when i try to run, I get this: 2008-09-22T08:43:48Z llrender/llfontgl.cpp(810) : error 2008-09-22T08:43:48Z ERROR: render: Missing Glyph Info I've also built the client on Win32, as well as i386 ubuntu and get the same error, so I know it must be something I'm doing wrong. I've searched Google and the SL wiki but to no avail. Any help would be appreciated, of course. :-) Thank you, -- Doug Barbieri dooglio@gmail.com From robin.cornelius at gmail.com Mon Sep 22 02:05:42 2008 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Sep 22 02:05:45 2008 Subject: [sldev] Also first time build...getting "Missing Glyph Info" In-Reply-To: <367cdf400809220150h2f082aadrd949910985e44ec7@mail.gmail.com> References: <367cdf400809220150h2f082aadrd949910985e44ec7@mail.gmail.com> Message-ID: On Mon, Sep 22, 2008 at 9:50 AM, R. Douglas Barbieri wrote: > Hi all, > > I'm new to the SL open source thing, and I am trying to run a trunk > build on my AMD64 ubuntu linux box. > > I managed to get everything to build as standalone using the cmake > system, and when i try to run, I get this: > > 2008-09-22T08:43:48Z llrender/llfontgl.cpp(810) : error > 2008-09-22T08:43:48Z ERROR: render: Missing Glyph Info > > I've also built the client on Win32, as well as i386 ubuntu and get > the same error, so I know it must be something I'm doing wrong. I've > searched Google and the SL wiki but to no avail. Any help would be > appreciated, of course. :-) This is an indication that the viewer could not find the required fonts. Overlay the libs package that is associated with the version you are using (it only contains the fonts now) by which i mean, download the libs package which is either listed on the source download page OR in docs/asset_urls.txt then unpack this on top of your source tree. You may need to force a rebuild as i'm not 100% sure what the packaging scripts do and they may copy the font files if present to a staging area. Another solution is to edit the app_settings.xml and change the 3 font files listed in there to 3 fonts you do have on your system (you would want to do this if you want to use only free components) and the following font choice may not be optimal anyway. Index: ./indra/newview/app_settings/settings.xml =================================================================== --- ./indra/newview/app_settings/settings.xml (revision 374) +++ ./indra/newview/app_settings/settings.xml (working copy) @@ -3464,7 +3464,7 @@ Type String Value - profontwindows.ttf + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf FontSansSerif @@ -3475,7 +3475,7 @@ Type String Value - MtBkLfRg.ttf + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf FontSansSerifBold @@ -3486,7 +3486,7 @@ Type String Value - MtBdLfRg.ttf + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf FontSansSerifFallback For example Robin From franclin.rhode at yahoo.com Mon Sep 22 07:29:56 2008 From: franclin.rhode at yahoo.com (Franclin Rhode) Date: Mon Sep 22 07:30:00 2008 Subject: [sldev] real life architectural design packages Message-ID: <519187.18537.qm@web59913.mail.ac4.yahoo.com> Dear all, How are you? I hope everything is going on well with you in the exploration in SL. Could you please help me with a question? Is there?any real life architectual design packages, such as?AutoCAD, Revit, ArchiCAD, 3D Studio max, etc that we can input directly into SL? I mean, if I already have a building model which is constructed in real life by Computer-Aided Architecture Design (CAAD), can I input that model directly into SL so that I do not have to build it again in SL? If not, is there any software available for me to combine real life architecture and SL construction? ? Any feedback will be highly appreciated. All the best and take care, ? Franclin Rhode -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080922/11db228d/attachment.htm From impalah at gmail.com Mon Sep 22 07:43:57 2008 From: impalah at gmail.com (Impalah) Date: Mon Sep 22 07:44:01 2008 Subject: [sldev] real life architectural design packages In-Reply-To: <519187.18537.qm@web59913.mail.ac4.yahoo.com> References: <519187.18537.qm@web59913.mail.ac4.yahoo.com> Message-ID: There isn't any "direct exporting" solution because CAD/3D programs are completely different to the way SL builds. For Autocad, check out Henshin, from my business "ai design studio" ( http://ai-designstudio.net/en/manual/henshin/introduction). We are developing the version V right now, to be launched in some weeks. greetings 2008/9/22 Franclin Rhode > Dear all, > > How are you? I hope everything is going on well with you in the exploration > in SL. Could you please help me with a question? > > Is there any real life architectual design packages, such as AutoCAD, > Revit, ArchiCAD, 3D Studio max, etc that we can input directly into SL? I > mean, if I already have a building model which is constructed in real life > by Computer-Aided Architecture Design (CAAD), can I input that model > directly into SL so that I do not have to build it again in SL? If not, is > there any software available for me to combine real life architecture and SL > construction? > > Any feedback will be highly appreciated. > All the best and take care, > > Franclin Rhode > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080922/c5d318fc/attachment.htm From dooglio at gmail.com Mon Sep 22 08:23:28 2008 From: dooglio at gmail.com (R. Douglas Barbieri) Date: Mon Sep 22 08:23:30 2008 Subject: [sldev] Also first time build...getting "Missing Glyph Info" In-Reply-To: References: <367cdf400809220150h2f082aadrd949910985e44ec7@mail.gmail.com> Message-ID: <367cdf400809220823u358e6e49h91645ddf7ce8a7b6@mail.gmail.com> Robin, thank you so much! That works perfectly, I tried your patch first, and that satisfied the font issue. I then grabbed the latest tarball with the linux libs and reverted the settings.xml file back and that worked as well. Thanks once again! On Mon, Sep 22, 2008 at 2:05 AM, Robin Cornelius wrote: > On Mon, Sep 22, 2008 at 9:50 AM, R. Douglas Barbieri wrote: >> Hi all, >> >> I'm new to the SL open source thing, and I am trying to run a trunk >> build on my AMD64 ubuntu linux box. >> >> I managed to get everything to build as standalone using the cmake >> system, and when i try to run, I get this: >> >> 2008-09-22T08:43:48Z llrender/llfontgl.cpp(810) : error >> 2008-09-22T08:43:48Z ERROR: render: Missing Glyph Info >> >> I've also built the client on Win32, as well as i386 ubuntu and get >> the same error, so I know it must be something I'm doing wrong. I've >> searched Google and the SL wiki but to no avail. Any help would be >> appreciated, of course. :-) > > > This is an indication that the viewer could not find the required fonts. > > Overlay the libs package that is associated with the version you are > using (it only contains the fonts now) by which i mean, download the > libs package which is either listed on the source download page OR in > docs/asset_urls.txt then unpack this on top of your source tree. You > may need to force a rebuild as i'm not 100% sure what the packaging > scripts do and they may copy the font files if present to a staging > area. > > Another solution is to edit the app_settings.xml and change the 3 font > files listed in there to 3 fonts you do have on your system (you would > want to do this if you want to use only free components) and the > following font choice may not be optimal anyway. > > > Index: ./indra/newview/app_settings/settings.xml > =================================================================== > --- ./indra/newview/app_settings/settings.xml (revision 374) > +++ ./indra/newview/app_settings/settings.xml (working copy) > @@ -3464,7 +3464,7 @@ > Type > String > Value > - profontwindows.ttf > + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf > > FontSansSerif > > @@ -3475,7 +3475,7 @@ > Type > String > Value > - MtBkLfRg.ttf > + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf > > FontSansSerifBold > > @@ -3486,7 +3486,7 @@ > Type > String > Value > - MtBdLfRg.ttf > + /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf > > FontSansSerifFallback > > > For example > > Robin > -- Doug Barbieri dooglio@gmail.com From dirk.krause at pixelpark.com Mon Sep 22 11:34:12 2008 From: dirk.krause at pixelpark.com (Dirk Krause) Date: Mon Sep 22 11:34:18 2008 Subject: [sldev] real life architectural design packages References: <519187.18537.qm@web59913.mail.ac4.yahoo.com> Message-ID: <72C1C9E5780A134F896530D480F22BB702142763@hermes.bitlab.de> Hi, there is a plugin called prim composer http://liferain.com/ (see Dusan Writers entry here: http://dusanwriter.com/?p=931 ) which seems to work. As far as I understood you are still limited to simple geometric building blocks, so you still have to model with the export in mind. Best regards, Dirk ________________________________ Von: sldev-bounces@lists.secondlife.com im Auftrag von Franclin Rhode Gesendet: Mo 22.09.2008 16:29 An: sldev@lists.secondlife.com Betreff: [sldev] real life architectural design packages Dear all, How are you? I hope everything is going on well with you in the exploration in SL. Could you please help me with a question? Is there any real life architectual design packages, such as AutoCAD, Revit, ArchiCAD, 3D Studio max, etc that we can input directly into SL? I mean, if I already have a building model which is constructed in real life by Computer-Aided Architecture Design (CAAD), can I input that model directly into SL so that I do not have to build it again in SL? If not, is there any software available for me to combine real life architecture and SL construction? Any feedback will be highly appreciated. All the best and take care, Franclin Rhode -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080922/1f649a80/attachment-0001.htm From grant at lindenlab.com Mon Sep 22 15:41:44 2008 From: grant at lindenlab.com (Grant Linden) Date: Mon Sep 22 15:41:47 2008 Subject: [sldev] RX Office hours - General Discussion topic: "Feature requests for little changes that make a huge difference" Message-ID: <907af5560809221541y70027696tcaf18e3c0081c6e9@mail.gmail.com> RX Office hours - General Discussion topic: "Feature requests for little changes that make a huge difference" Thursday September 25th from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our new wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux -- Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080922/bd2103a2/attachment.htm From kf6kjg at gmail.com Mon Sep 22 23:13:09 2008 From: kf6kjg at gmail.com (Ricky) Date: Mon Sep 22 23:13:11 2008 Subject: [sldev] Voice on 64bit Linux Message-ID: <3bb9647e0809222313v3114a30bm7cd42be7c74d6868@mail.gmail.com> I have been having many fits and starts with voice since it's release, and I'd love to have it working.. So I upped the log level in the client. (Advanced > Debug Settings > VivoxDebugLevel = 5) Here's the specs section from the Connector log: 20:26:34.0000, 0xf73df6c0, INFO , initialize Machine Configuration= 001A929726A8 Linux Linux version 2.6.25-gentoo-r7 (root@glave) (gcc version 4.1.2 20070214 ( (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2 p1.1)) #1 SMP Thu Aug 14 22:07:27 PDT 2008 AuthenticAMD.17155.15.2 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ 3013.882 3965 20:26:34.0000, 0xf73df6c0, INFO , initialize Sdk Configuration= 2.1.2990.3400 ALSA Capture on default ALSA Capture on HDA NVidia ALSA Capture on USB Device 0x41e:0x4048 ALSA Capture on SB X-Fi Surround 5.1 OSS Capture ALSA Software on default ALSA Software on HDA NVidia [AD198x Analog] ALSA Software on HDA NVidia [AD198x Digital] ALSA Software on SB X-Fi Surround 5.1 [USB Audio] ALSA Software on SB X-Fi Surround 5.1 [USB Audio #1] OSS Software Wave File Writer ALSA Capture on default I also paid attention to the SLVoice log found in ~/Library/Logs/Vivox For some reason it's having tribbles connecting to my recording device (any one of them) but that's ok, other apps have issues too with finding my mic.. I would like to be able to at least listen to my friend's conversations! :D Here's my question: Is there a dependency on a system copy of mediastreamer from linphone? I ask beacuse of these lines from the Connector log: 20:26:34.0000, 0xf73df6c0, INFO , RTP oRTP-0.11.2 initialized. 20:26:35.0000, 0xf73df6c0, INFO , RTP Card OPENAL: ALSA Capture on default added 20:26:35.0000, 0xf73df6c0, INFO , RTP Cannot open directory /usr/local/antisip/lib/mediastreamer/plugins: No such file or directory 20:26:35.0000, 0xf73df6c0, ERROR, RTP No such filter with id 28 20:26:35.0000, 0xf73df6c0, INFO , am_options.c:340 Range audio port start at: 22860 20:26:35.0000, 0xf73df6c0, TRACE, vx_sip_and_media_mgr_init Exiting vx_sip_and_media_mgr_init successfully 20:26:35.0000, 0xf73df6c0, TRACE, initialize In initialize, creating request processor thread On Gentoo, media-libs/mediastreamer is hard masked. Meaning that it is considered too unstable to allow any but the very determined to install it. Thanks, Ricky aka Cron Stardust -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080922/34701384/attachment.htm From bill.hoffman at kitware.com Tue Sep 23 10:08:25 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Tue Sep 23 10:08:49 2008 Subject: [sldev] cmake 2.6.2 RC 6 Message-ID: <48D92289.20003@kitware.com> I have a release candidate (RC 6) for 2.6.2 ready for CMake. There is one small fix over RC 5. I fixed cpack so it would run from a symlink, which fixes the command line install on Mac OSX when the application bundle is used. If there are no issues by the morning I will do a release tomorrow. This version should work for SL Windows, Linux, and Xcode. Thanks. The files can be found here: http://www.cmake.org/files/v2.6/*RC-6* The changes from 2.6.2 to 2.6.1 are as follows: Changes in CMake 2.6.2 RC 6 - Fix bug#7669 cpack did not work when sym-linked after install Changes in CMake 2.6.2 RC 5 - Add beta BundleUtilities.cmake file - CPackRPM 7435 fixes to add optional post-install - Fix Bug #7456, FindBoost versioned find not working - Fix FindCurses to be able to work without ncurses.h - FindQt4 fix bug #7433, add a bit more documentation and add ability to specify extra flags to lupdate. Changes in CMake 2.6.2 RC 4 - Fix bug #7359 make llvm-gcc work, by explicitely excluding "llvm-" from _CMAKE_TOOLCHAIN_PREFIX - Fix bug 7046: OS X Framework support: extensionless headers were being ignored when specified as public headers - Fix documentation in CheckCCompilerFlag.cmake - Add better version support to find_package command - Fix Xcode debug not working - Add VERSION compare to if command - Make FindThreads sete THREADS_FOUND - Deb cpack generator sets Installed-Size for the package - Do not add an empty /D"" at the end of VS 6 .dsp compile lines - Recognize /MAP in VS 7 and greater - Add new policy CMP0009 - GLOB_RECURSE should not follow symlinks by default Changes in CMake 2.6.2 RC 3 - Fix bug, and remove extra closing > in visual fortran projects. - Fix bug in ctest -C where it was sometimes ignored. - Fix crash with exec_process when cmake is being debugged on windows - Fix unsetting of global properties Changes in CMake 2.6.2 RC 2 - allow tool chains to limit object path length - add info.plist to frameworks - better preservation of user link lines - add a get command for cmake policies - support for imported libraries of unknown type - support link interface in target_link_libraries - Do not hang when select lies - .m compiled with gcc and g++ on mac - Fix issue when application bundle dir is removed cmake needs to re-run automatically - Report an error when configure has one error - Fix bug where -E commands stole command line options - Fix infinite recursion bug with try-compile and change of compilers - Fix delete and backspace in ccmake - Fix coverage not to follow symlinks - Add more possible languages for NSIS in cpack - FindQt4.cmake fix bug #7433, add documentation that directories also can be specified to update the translation files. - Add standard arg handling to FindPHP4.cmake - Add X11R6 to search path for FindOpenGL - update cmake-syntax.vim to have more keywords - BUG: fix #7477, set VERBOSE=1 in the kdevelop setting for the environment, not together with the make executable - UsePkgConfig.cmake - clean up, add a status message in case pkgconfig didn't find the package, sync with kde - FindX11 look in more places - FindTIFF look for more names - FindQt3, make sure qt4 is not found and some style stuff - FindPNG add more names of linpng (sync with the KDE version) - FindKDE3/KDE4 sanity checks on qt versions found - FindLibXMl2 also search for xmllint, which comes with libxml2 (sync with FindLibXml2.cmake from KDE) - Fix sizeof, and other compiler INFO string checks with GNU linker's --gc-sections - Fix bogus dependency on executable targets when a linked library happended to match the name of an executable target - Improve readability of circular depends error - Fix crash on circular target dependencies - find_package now knows about lib64 paths - Fix gentoo elf security issue with RPATH and RUNPATH Changes in CMake 2.6.2 RC 1 - Fix abort in eclipse generator with empty EXECUTABLE_OUTPUT_PATH - Fix FindKDE3.cmake syntax error - Fix custom command output by relative path not always working - Fix bug, Do not convert RPATH entries to full path. - Allow for "$ORIGIN" into the RPATH> - Allow for static libraries with lots of objects using archive append - Fix documentation for FindImageMagick.cmake - Fix link error with MS compiler and comdef - Fix crash when attempting to load the RPATH out of a non-ELF file - Add --trace option to cmake allowing for the tracing of a cmake run - Fix for issue #4971 where the case of the drive letter component of the filenames might be different when analyzing gcov output. - Add warning level W0 to visual studio - Add support for OSX library version flags From jpirkola at gmail.com Wed Sep 24 15:57:04 2008 From: jpirkola at gmail.com (Jani Pirkola) Date: Wed Sep 24 15:57:07 2008 Subject: [sldev] [ANNOUNCEMENT] 0.31 version of realXtend is available now Message-ID: <9291786d0809241557p65b7d34dr7809eade78b15bd8@mail.gmail.com> Dear all, Version 0.31 of the realXtend platform includes several new features, such as smoother transition between worlds, global inventory and HDR effects for the viewer. Downloads are available at the realXtend.org website. With this latest version you can also send instant messages to your friends from one realXtend world to another and user rights management for world servers has been improved as well. realXtend is a platform that includes all the necessary components for creating a network of independent and interconnected virtual worlds. The avatar services are separated from the worlds, enabling them to travel freely through the realXtend network and take their inventory with them wherever they go. The avatars are highly sophisticated and modifiable and the worlds can be populated with mesh objects in addition to primitives. Best regards, Jani Pirkola realXtend program manager -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080925/88ca46b1/attachment.htm From agati at procele.com.br Wed Sep 24 20:34:50 2008 From: agati at procele.com.br (Salvador Agati) Date: Wed Sep 24 20:34:55 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> Message-ID: ----- Original Message ----- From: John Hurliman To: Carsten Juttner Cc: Second Life Developer Mailing List Sent: Sunday, September 21, 2008 1:05 AM Subject: Re: [sldev] Meaning of RequestImage DiscardLevel field? Thank you Carsten, that clarification is correct. For now I'm assuming that DiscardLevel 0 is a request for the full quality (zero discarded levels) and DiscardLevel 5 is requesting the lowest quality level. However, if you start with five quality layers and you discard five of them what are you left with? Is five actually being clamped to four? This still doesn't explain -1. If you send a RequestImage with Priority = 0.0 and DiscardLevel = -1 it will cancel the download, but texture requests often start with a positive priority and a DiscardLevel of -1. Is this a request for the header only, or is it just an uninitialized value in the client that implies zero or four? John On Fri, Sep 19, 2008 at 3:45 PM, Carsten Juttner wrote: Robin Cornelius wrote: John Hurliman wrote: I know that the DiscardLevel field in the RequestImage packet is used to request different quality levels (not different texture sizes as the protocol documentation states, SL uses LRCP ordered JPEG2000 files), but i can't figure out what the values correspond to. In a typical texture download I'll see values ranging from -1 to 5. Is -1 a special value? Is there an upper limit? Does a larger number mean a lower quality layer? The discard field is directly related to the request quality level as you are already aware. It should be a simple calculation that the discard is the number of powers of 2 to scale the image down by for the reduced quality. So a discard of 0 is the complete image and a discard of 1 is a 1/2 size, a discard of 2 is a 1/4 size etc. I think what John was actually referring to here is that quality layers and resolution levels are not the same. In JPEG2k all data is divided into packets for one tile. Each packet contains codestream data for one quality layer for one resolution for one component for one precinct (spatial partition). The order in which you transmit the packets decides what you get first and is signalled by the "progression order". LRCP (Layer-Resolution-Component-Position) is layer-centric meaning that one by one you get all the data for each quality layer, not for each resolution. That means you end up with the lowest quality layer for all resolutions first so it's really a quality-based progression, not a resolution-based. Think of the quality layers as going down the bits from MSB to LSB. First you get the rough information, then it progresses to the detailed information (actually for the wavelet coefficients). AFAIK, inside the viewer the progression order is not really cared about and the discard levels are merely referring to the dropped resolutions from the highest resolution. Also nobody seems to really know what is happening on the server side since we did ask a while ago but never met a Linden who was familiar with that area of the code so it's still a bit of a mystery. Regards, Carsten I'm not used to post here and I' ve got only these 2 messages above related to the subject. Indeed , english is not my native language and I am concious that I'm not an expert as you, in this list, are. Despite of that, I decided to send this post because one of the first things I noted when I began to discover SL was exactly the way images were loaded in the viewer. It reminded me when I, after the college, was a mastering student and had to read and discuss, in the class, the implementation of an algoritm . I happened at about 20 years ago. In this book, it was presented an algoritm called "gross information first" and it used in the formula, power of 2 numbers to calculate the pixel value of a group of pixels of a image. So, the quality of the image generated with the algoritm was related to 2, 4, 8, 16, 32 or thinking as power of 2, the values 0,1,2,3,4,5 . I was wondering if this is the case, where the viewer asks for the next quality layer after the previous layer loaded and -1 to ask for data without this type of filtering. In this situation, the image, in the server, would be stored only with the highest quality and the server would first "filter" the image, with the correct factor, and then, send it to the viewer, progressively, as requested. If someone call me crazy , I won't deny. Regards, Agathos Frascati SL Salvador Agati RL -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080925/fa4433fa/attachment.htm From vandana.a at samsung.com Wed Sep 24 23:11:40 2008 From: vandana.a at samsung.com (Vandana) Date: Wed Sep 24 23:09:17 2008 Subject: [sldev] EnableSimulator not received Message-ID: <041801c91ed5$949f3960$12486c6b@sisodomain.com> Hi, Would like to know what triggers SL server to send EnableSimulator packet to SL Client. >From my point of view if AgentUpdate is continuously sent to server with visibility area which let the server detect that Agent can view nearby region and hence send the EnableSimulator packet. But while experimenting, I observed this is not only the reason of getting the EnableSimulator. So I am curious to know what packet from Client triggers EnableSimulator from server. Regards Vandana -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080925/399c5fce/attachment.htm From gareth at litesim.com Wed Sep 24 23:40:07 2008 From: gareth at litesim.com (Gareth Nelson) Date: Wed Sep 24 23:40:09 2008 Subject: [sldev] EnableSimulator not received In-Reply-To: <041801c91ed5$949f3960$12486c6b@sisodomain.com> References: <041801c91ed5$949f3960$12486c6b@sisodomain.com> Message-ID: <61dbdd7d0809242340g5694ef55hec1211dc9a7d71c5@mail.gmail.com> > So I am curious to know what packet from Client triggers EnableSimulator > from server. Surely it's more complex than a single packet triggering this? My bets would lie with the render distance (part of the view frustum - however you spell that) and AgentUpdate as well as initial region handshake. From geenz at geenzo.com Thu Sep 25 10:01:59 2008 From: geenz at geenzo.com (Jonathan Goodman) Date: Thu Sep 25 10:02:57 2008 Subject: [sldev] [HELP] errors compiling shadow-draft-3 Message-ID: <982AD97632C9744BA93AC658AD94F2651AE09B@ntxbeus20.exchange.xchg> Skipped content of type multipart/alternative-------------- next part -------------- Compiling... pipeline.cpp pipeline.cpp(5715) : error C3861: 'llgaussian': identifier not found, even with argument-dependent lookup pipeline.cpp(5716) : error C3861: 'llgaussian': identifier not found, even with argument-dependent lookup pipeline.cpp(6510) : error C2039: 'FTM_SHADOW_RENDER' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' pipeline.cpp(6510) : error C2065: 'FTM_SHADOW_RENDER' : undeclared identifier pipeline.cpp(6547) : error C2039: 'FTM_SHADOW_SIMPLE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' pipeline.cpp(6547) : error C2065: 'FTM_SHADOW_SIMPLE' : undeclared identifier pipeline.cpp(6558) : error C2039: 'FTM_SHADOW_ALPHA' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' pipeline.cpp(6558) : error C2065: 'FTM_SHADOW_ALPHA' : undeclared identifier llfasttimerview.cpp llfasttimerview.cpp(164) : error C2039: 'FTM_SHADOW_RENDER' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(164) : error C2065: 'FTM_SHADOW_RENDER' : undeclared identifier llfasttimerview.cpp(165) : error C2039: 'FTM_SHADOW_SIMPLE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(165) : error C2065: 'FTM_SHADOW_SIMPLE' : undeclared identifier llfasttimerview.cpp(166) : error C2039: 'FTM_SHADOW_ALPHA' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(166) : error C2065: 'FTM_SHADOW_ALPHA' : undeclared identifier llfasttimerview.cpp(167) : error C2039: 'FTM_SHADOW_TERRAIN' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(167) : error C2065: 'FTM_SHADOW_TERRAIN' : undeclared identifier llfasttimerview.cpp(168) : error C2039: 'FTM_SHADOW_AVATAR' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(168) : error C2065: 'FTM_SHADOW_AVATAR' : undeclared identifier llfasttimerview.cpp(169) : error C2039: 'FTM_SHADOW_TREE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' llfasttimerview.cpp(169) : error C2065: 'FTM_SHADOW_TREE' : undeclared identifier lldrawpooltree.cpp lldrawpooltree.cpp(94) : error C2039: 'FTM_SHADOW_TREE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpooltree.cpp(94) : error C2065: 'FTM_SHADOW_TREE' : undeclared identifier lldrawpooltree.cpp(164) : error C2039: 'FTM_SHADOW_TREE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpooltree.cpp(164) : error C3861: 'FTM_SHADOW_TREE': identifier not found, even with argument-dependent lookup lldrawpooltree.cpp(176) : error C2039: 'FTM_SHADOW_TREE' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpooltree.cpp(176) : error C3861: 'FTM_SHADOW_TREE': identifier not found, even with argument-dependent lookup lldrawpoolterrain.cpp lldrawpoolterrain.cpp(260) : error C2039: 'FTM_SHADOW_TERRAIN' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolterrain.cpp(260) : error C2065: 'FTM_SHADOW_TERRAIN' : undeclared identifier lldrawpoolterrain.cpp(268) : error C2039: 'FTM_SHADOW_TERRAIN' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolterrain.cpp(268) : error C3861: 'FTM_SHADOW_TERRAIN': identifier not found, even with argument-dependent lookup lldrawpoolterrain.cpp(275) : error C2039: 'FTM_SHADOW_TERRAIN' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolterrain.cpp(275) : error C3861: 'FTM_SHADOW_TERRAIN': identifier not found, even with argument-dependent lookup lldrawpoolsimple.cpp lldrawpool.cpp lldrawpoolbump.cpp lldrawpoolavatar.cpp lldrawpoolavatar.cpp(251) : error C2039: 'FTM_SHADOW_AVATAR' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolavatar.cpp(251) : error C2065: 'FTM_SHADOW_AVATAR' : undeclared identifier lldrawpoolavatar.cpp(273) : error C2039: 'FTM_SHADOW_AVATAR' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolavatar.cpp(273) : error C3861: 'FTM_SHADOW_AVATAR': identifier not found, even with argument-dependent lookup lldrawpoolavatar.cpp(287) : error C2039: 'FTM_SHADOW_AVATAR' : is not a member of 'LLFastTimer' C:\Users\Geenz\Dev\SL\shadow-draft-3\indra\llcommon\llfasttimer.h(40) : see declaration of 'LLFastTimer' lldrawpoolavatar.cpp(287) : error C3861: 'FTM_SHADOW_AVATAR': identifier not found, even with argument-dependent lookup From soft at lindenlab.com Thu Sep 25 10:08:15 2008 From: soft at lindenlab.com (Soft) Date: Thu Sep 25 10:08:18 2008 Subject: [sldev] [HELP] errors compiling shadow-draft-3 In-Reply-To: <982AD97632C9744BA93AC658AD94F2651AE09B@ntxbeus20.exchange.xchg> References: <982AD97632C9744BA93AC658AD94F2651AE09B@ntxbeus20.exchange.xchg> Message-ID: I've forwarded this to the branch owner. On Thu, Sep 25, 2008 at 12:01 PM, Jonathan Goodman wrote: > Hi- > > I recently attempted to build the latest SVN commit of the shadow-draft-3 > branch, and ran across some errors regarding FTM_SHADOW_AVATAR, llgaussian, > FTM_SHADOW_SIMPLE, FTM_SHADOW_RENDER, FTM_SHADOW_ALPHA, FTM_SHADOW_TREE, and > FTM_SHADOW_TERRAIN. I've attached a file showing the errors. I'm using > Visual Studio 2003 .NET, and have been able to successfully compile previous > iterations of the shadow-draft branches. > > __________ Information from ESET Smart Security, version of virus signature > database 3471 (20080925) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From soft at lindenlab.com Thu Sep 25 10:14:24 2008 From: soft at lindenlab.com (Soft) Date: Thu Sep 25 10:14:27 2008 Subject: [sldev] [HELP] errors compiling shadow-draft-3 In-Reply-To: References: <982AD97632C9744BA93AC658AD94F2651AE09B@ntxbeus20.exchange.xchg> Message-ID: shadow-draft-3 is a merge branch with a deceptive name, and will be broken for a bit. I'm yanking this and will republish either this or the final location of the shadow draft work when all is complete. On Thu, Sep 25, 2008 at 12:08 PM, Soft wrote: > I've forwarded this to the branch owner. > > On Thu, Sep 25, 2008 at 12:01 PM, Jonathan Goodman wrote: >> Hi- >> >> I recently attempted to build the latest SVN commit of the shadow-draft-3 >> branch, and ran across some errors regarding FTM_SHADOW_AVATAR, llgaussian, >> FTM_SHADOW_SIMPLE, FTM_SHADOW_RENDER, FTM_SHADOW_ALPHA, FTM_SHADOW_TREE, and >> FTM_SHADOW_TERRAIN. I've attached a file showing the errors. I'm using >> Visual Studio 2003 .NET, and have been able to successfully compile previous >> iterations of the shadow-draft branches. >> >> __________ Information from ESET Smart Security, version of virus signature >> database 3471 (20080925) __________ >> >> The message was checked by ESET Smart Security. >> >> http://www.eset.com >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > From tinacloud at gmx.de Thu Sep 25 11:00:22 2008 From: tinacloud at gmx.de (Zi Ree) Date: Thu Sep 25 11:00:28 2008 Subject: [sldev] Updating inventory item icon Message-ID: <200809252000.22909.tinacloud@gmx.de> Hi Developers! I am working on a patch that makes Landmarks behave as intended, i.e. turning to "Visited" state once you have been there. The patch itself works already, but the icon is not updated in real time. Opening a second inventory window shows the new state of the landmark. What do I have to do in order to change the icon of an existing inventory entry? The source code says, the inventory observer must be notified, and this is done in the original code. However, it doesn't work. (You can see the code in LLTracker::setLandmarkVisited(), near the end of the function.) Any hints? Thanks for your time! Zi! From teravus at gmail.com Thu Sep 25 11:20:06 2008 From: teravus at gmail.com (Teravus Ovares) Date: Thu Sep 25 11:20:08 2008 Subject: [sldev] EnableSimulator not received In-Reply-To: <041801c91ed5$949f3960$12486c6b@sisodomain.com> References: <041801c91ed5$949f3960$12486c6b@sisodomain.com> Message-ID: <34cc66250809251120u4e9ce96eg14cd2fa5a734e35e@mail.gmail.com> Well, I can tell you what causes OpenSimulator to send that message. Essentially. Any time the server that you're on wants you to connect to another simulator. This includes establishing child agents and is a prerequisite to 'see into' regions that you're not current in, but are connected to and are getting updates. As far as 'how' the sim knows to connect you to another simulator.. It determines that your camera 'view' overlaps with a border where there is a neighbor simulator that it hasn't told you about. Then it 'tells the neighbor simulator over region<--->region communications about you, where you are, where your camera is and it's settings. Then once it tells the neighbor simulator about you, it sends you the 'EnableSimulator' packet Teleporting also has several grid communication components that end up in telling your client about a simulator to connect to, and then handing you off. Sometimes your connection times out on regions where you're a 'child agent' in. This causes the region you're a child agent in to inform the region that you're actually in(root agent) that it lost connection with you.. then the sim that you're in determines if it can still contact you.. if it can, it re-sends the EnableSimulator packet to re-establish the child agent connection. When this happens, sometimes you'll see regions become red on the mini-map/map, and then turn green again. Anyway.. I know OpenSimulator isn't LL's SVC, but I hope I answered some of your questions anyway. Best Regards Teravus On 9/25/08, Vandana wrote: > > Hi, > > Would like to know what triggers SL server to send EnableSimulator packet to > SL Client. > > From my point of view if AgentUpdate is continuously sent to server with > visibility area which let the server detect that Agent can view nearby > region and hence send the EnableSimulator packet. > > But while experimenting, I observed this is not only the reason of getting > the EnableSimulator. > > So I am curious to know what packet from Client triggers EnableSimulator > from server. > > Regards > Vandana > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From teravus at gmail.com Thu Sep 25 11:40:58 2008 From: teravus at gmail.com (Teravus Ovares) Date: Thu Sep 25 11:41:01 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> Message-ID: <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> Once again, I know this is speculation.. however I ran some tests on this a few months back. I attempted to send the discard levels as individual images, and the first discard level requested came through, however, subsequent 'images' sent representing the next level of discard level caused it to corrupt the image client side. This leads me to believe that the discard levels represent byte offsets of where the boundary between the packets that represent the discard levels are.. as far as the server is concerned. So, in other words.. lets say you have 5 discard levels in an image. You'd have to know this before hand in meta data or decode it on the fly. The client asks for discard level 5... We send it bytes 0-1000. The client asks for discard level 3 of the same image.. we know it has already received the discard level 5 bytes.. so we send bytes 1001-5000. .. and we keep appending the rest of the file based on the packets in the file This implies that the packets are ordered in sequence from lowest at the beginning to highest at the end. Sometimes we get requests on the simulator for -1 before the rest of the discard levels are requested. Sometimes we get requests on the simulator for -1 when the third discard level is requested.. It seems to have to do with defining and keeping image priority. On a Linden Simulator, it appears that there's an image priority queue that it uses to feed the clients images at different discard levels and keep track of the ones it has previously sent. It also seems to reorder them in the priority 'list' that the server keeps. But!, it would be nice to get a LL Developer's view on what Discard Level actually represents. Best Regards Teravus On 9/24/08, Salvador Agati wrote: > > > > ----- Original Message ----- > From: John Hurliman > To: Carsten Juttner > Cc: Second Life Developer Mailing List > Sent: Sunday, September 21, 2008 1:05 AM > Subject: Re: [sldev] Meaning of RequestImage DiscardLevel field? > > > Thank you Carsten, that clarification is correct. For now I'm assuming that > DiscardLevel 0 is a request for the full quality (zero discarded levels) and > DiscardLevel 5 is requesting the lowest quality level. However, if you start > with five quality layers and you discard five of them what are you left > with? Is five actually being clamped to four? This still doesn't explain -1. > If you send a RequestImage with Priority = 0.0 and DiscardLevel = -1 it will > cancel the download, but texture requests often start with a positive > priority and a DiscardLevel of -1. Is this a request for the header only, or > is it just an uninitialized value in the client that implies zero or four? > > John > > > On Fri, Sep 19, 2008 at 3:45 PM, Carsten Juttner wrote: > > > > > > Robin Cornelius wrote: > > > > John Hurliman wrote: > > > > I know that the DiscardLevel field in the RequestImage packet is used > to request different quality levels (not different texture sizes as > the protocol documentation states, SL uses LRCP ordered JPEG2000 files), > but i can't figure out what the values correspond to. In a typical > texture download I'll see values ranging from -1 to 5. Is -1 a special > value? Is there an upper limit? Does a larger number mean a lower quality > layer? > > The discard field is directly related to the request quality level as you > are already aware. It should be a simple calculation that the discard is the > number of powers of 2 to scale the image down by for the reduced quality. So > a discard of 0 is the complete image and a discard of 1 is a 1/2 size, a > discard of 2 is a 1/4 size etc. > > > > I think what John was actually referring to here is that quality layers > and resolution levels are not the same. In JPEG2k all data is divided into > packets for one tile. Each packet contains codestream data for one quality > layer for one resolution for one component for one precinct (spatial > partition). The order in which you transmit the packets decides what you get > first and is signalled by the "progression order". LRCP > (Layer-Resolution-Component-Position) is layer-centric > meaning that one by one you get all the data for each quality layer, not for > each resolution. That means you end up with the lowest quality layer for all > resolutions first so it's really a quality-based progression, not a > resolution-based. > > > > Think of the quality layers as going down the bits from MSB to LSB. First > you get the rough information, then it progresses to the detailed > information (actually for the wavelet coefficients). > > > > AFAIK, inside the viewer the progression order is not really cared about > and the discard levels are merely referring to the dropped resolutions from > the highest resolution. > > > > Also nobody seems to really know what is happening on the server side > since we did ask a while ago but never met a Linden who was familiar with > that area of the code so it's still a bit of a mystery. > > > > Regards, > > Carsten > > > > > > > > > > I'm not used to post here and I' ve got only these 2 messages above > related to the subject. Indeed , english is not my native language and I am > concious that I'm not an expert as you, in this list, are. > > > > Despite of that, I decided to send this post because one of the first > things I noted when I began to discover SL was exactly the way images were > loaded in the viewer. > > > > It reminded me when I, after the college, was a mastering student and had > to read and discuss, in the class, the implementation of an algoritm . I > happened at about 20 years ago. > > > > In this book, it was presented an algoritm called "gross information > first" and it used in the formula, power of 2 numbers to calculate the > pixel value of a group of pixels of a image. So, the quality of the image > generated with the algoritm was related to 2, 4, 8, 16, 32 or thinking as > power of 2, the values 0,1,2,3,4,5 . > > > > I was wondering if this is the case, where the viewer asks for the next > quality layer after the previous layer loaded and -1 to ask for data without > this type of filtering. > > > > In this situation, the image, in the server, would be stored only with > the highest quality and the server would first "filter" the image, with the > correct factor, and then, send it to the viewer, progressively, as > requested. > > > > If someone call me crazy , I won't deny. > > > > Regards, > > Agathos Frascati SL > > Salvador Agati RL > > > > > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From gareth at litesim.com Thu Sep 25 11:41:45 2008 From: gareth at litesim.com (Gareth Nelson) Date: Thu Sep 25 11:41:47 2008 Subject: [sldev] EnableSimulator not received In-Reply-To: <34cc66250809251120u4e9ce96eg14cd2fa5a734e35e@mail.gmail.com> References: <041801c91ed5$949f3960$12486c6b@sisodomain.com> <34cc66250809251120u4e9ce96eg14cd2fa5a734e35e@mail.gmail.com> Message-ID: <61dbdd7d0809251141s6c548c3fu22f6ad8d1eafe5b1@mail.gmail.com> Opensim actually sends EnableSimulator for all 8 possible neighbours at startup. (I know this because I was the one to put multiple sim support into it in the first place). LL's sims use a more sophisticated setup which is dependent on your viewer frustum (i'll spell it right one day!) On Thu, Sep 25, 2008 at 7:20 PM, Teravus Ovares wrote: > Well, I can tell you what causes OpenSimulator to send that message. > > Essentially. Any time the server that you're on wants you to connect > to another simulator. > > This includes establishing child agents and is a prerequisite to 'see > into' regions that you're not current in, but are connected to and are > getting updates. > > As far as 'how' the sim knows to connect you to another simulator.. > It determines that your camera 'view' overlaps with a border where > there is a neighbor simulator that it hasn't told you about. Then it > 'tells the neighbor simulator over region<--->region communications > about you, where you are, where your camera is and it's settings. > Then once it tells the neighbor simulator about you, it sends you the > 'EnableSimulator' packet > > Teleporting also has several grid communication components that end up > in telling your client about a simulator to connect to, and then > handing you off. > > Sometimes your connection times out on regions where you're a 'child > agent' in. This causes the region you're a child agent in to inform > the region that you're actually in(root agent) that it lost connection > with you.. then the sim that you're in determines if it can still > contact you.. if it can, it re-sends the EnableSimulator packet to > re-establish the child agent connection. When this happens, sometimes > you'll see regions become red on the mini-map/map, and then turn green > again. > > Anyway.. I know OpenSimulator isn't LL's SVC, but I hope I answered > some of your questions anyway. > > Best Regards > > Teravus > > On 9/25/08, Vandana wrote: >> >> Hi, >> >> Would like to know what triggers SL server to send EnableSimulator packet to >> SL Client. >> >> From my point of view if AgentUpdate is continuously sent to server with >> visibility area which let the server detect that Agent can view nearby >> region and hence send the EnableSimulator packet. >> >> But while experimenting, I observed this is not only the reason of getting >> the EnableSimulator. >> >> So I am curious to know what packet from Client triggers EnableSimulator >> from server. >> >> Regards >> Vandana >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From bill.hoffman at kitware.com Fri Sep 26 11:23:53 2008 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Fri Sep 26 11:24:18 2008 Subject: [sldev] CMake 2.6.2 available for download Message-ID: <48DD28B9.90804@kitware.com> On behalf of myself, Ken, Brad, Dave, Alex and the rest of the CMake team, we are pleased to announce that CMake 2.6.2 is available for download at: http://www.cmake.org/cmake/resources/software.html If you have any problems or find any bugs, please report them at www.cmake.org/Bug. A list of changes for the 2.6 release tree is included below. Thanks Bill Changes in CMake 2.6.2 RC 6 - Fix bug#7669 cpack did not work when sym-linked after install Changes in CMake 2.6.2 RC 5 - Add beta BundleUtilities.cmake file - CPackRPM 7435 fixes to add optional post-install - Fix Bug #7456, FindBoost versioned find not working - Fix FindCurses to be able to work without ncurses.h - FindQt4 fix bug #7433, add a bit more documentation and add ability to specify extra flags to lupdate. Changes in CMake 2.6.2 RC 4 - Fix bug #7359 make llvm-gcc work, by explicitely excluding "llvm-" from _CMAKE_TOOLCHAIN_PREFIX - Fix bug 7046: OS X Framework support: extensionless headers were being ignored when specified as public headers - Fix documentation in CheckCCompilerFlag.cmake - Add better version support to find_package command - Fix Xcode debug not working - Add VERSION compare to if command - Make FindThreads sete THREADS_FOUND - Deb cpack generator sets Installed-Size for the package - Do not add an empty /D"" at the end of VS 6 .dsp compile lines - Recognize /MAP in VS 7 and greater - Add new policy CMP0009 - GLOB_RECURSE should not follow symlinks by default Changes in CMake 2.6.2 RC 3 - Fix bug, and remove extra closing > in visual fortran projects. - Fix bug in ctest -C where it was sometimes ignored. - Fix crash with exec_process when cmake is being debugged on windows - Fix unsetting of global properties Changes in CMake 2.6.2 RC 2 - allow tool chains to limit object path length - add info.plist to frameworks - better preservation of user link lines - add a get command for cmake policies - support for imported libraries of unknown type - support link interface in target_link_libraries - Do not hang when select lies - .m compiled with gcc and g++ on mac - Fix issue when application bundle dir is removed cmake needs to re-run automatically - Report an error when configure has one error - Fix bug where -E commands stole command line options - Fix infinite recursion bug with try-compile and change of compilers - Fix delete and backspace in ccmake - Fix coverage not to follow symlinks - Add more possible languages for NSIS in cpack - FindQt4.cmake fix bug #7433, add documentation that directories also can be specified to update the translation files. - Add standard arg handling to FindPHP4.cmake - Add X11R6 to search path for FindOpenGL - update cmake-syntax.vim to have more keywords - BUG: fix #7477, set VERBOSE=1 in the kdevelop setting for the environment, not together with the make executable - UsePkgConfig.cmake - clean up, add a status message in case pkgconfig didn't find the package, sync with kde - FindX11 look in more places - FindTIFF look for more names - FindQt3, make sure qt4 is not found and some style stuff - FindPNG add more names of linpng (sync with the KDE version) - FindKDE3/KDE4 sanity checks on qt versions found - FindLibXMl2 also search for xmllint, which comes with libxml2 (sync with FindLibXml2.cmake from KDE) - Fix sizeof, and other compiler INFO string checks with GNU linker's --gc-sections - Fix bogus dependency on executable targets when a linked library happended to match the name of an executable target - Improve readability of circular depends error - Fix crash on circular target dependencies - find_package now knows about lib64 paths - Fix gentoo elf security issue with RPATH and RUNPATH Changes in CMake 2.6.2 RC 1 - Fix abort in eclipse generator with empty EXECUTABLE_OUTPUT_PATH - Fix FindKDE3.cmake syntax error - Fix custom command output by relative path not always working - Fix bug, Do not convert RPATH entries to full path. - Allow for "$ORIGIN" into the RPATH> - Allow for static libraries with lots of objects using archive append - Fix documentation for FindImageMagick.cmake - Fix link error with MS compiler and comdef - Fix crash when attempting to load the RPATH out of a non-ELF file - Add --trace option to cmake allowing for the tracing of a cmake run - Fix for issue #4971 where the case of the drive letter component of the filenames might be different when analyzing gcov output. - Add warning level W0 to visual studio - Add support for OSX library version flags Changes in CMake 2.6.1 RC 16 - Fix for bug 7427, preinstall target name hard coded - Fix issue #7088 - do not emit error messages when attempts to run Visual Studio macros fail. You can still get the error output as messages if you want using --debug-output from the cmake command line. - Fix InstallRequiredSystemLibraries.cmake to work with win64 Changes in CMake 2.6.1 RC 15 - Fix bug 7426 FindJPEG module causes error when setting JPEG_LIBRARY to blank - Fix bug 7414 PackageMaker generator crashes when given components with circular dependencies - Fix source files to not add extra /, and look for extensions for all enabled languages. - Change link line to preserve input given to target_link_libraries even if a shared library is repeated. - Fix for bug 7421, fortran did not get arch flags on the mac - For CMP0008 do not depend on the files that are not there, which makes the Xcode generator delete executables after they are built. - Work around Boost 1.36.0 bug fix on Darwin by setting the mangled compiler name to -xgccVERSION - Updated FindImageMagick to: - Find newer additions such as animate, compare, etc. - Find development api: Magick++, MagickCore, MagickWand - Use FindPackageHandleStandardArgs to output standard messages. Changes in CMake 2.6.1 RC 14 - Change dashboard submission to go directly to CDash. - Add policy CMP0008- Full-path libraries must be a valid library file name Changes in CMake 2.6.1 RC 12 - More find locations for FindJNI. - Fix bug with source files ending in .l and .l.cpp, causing cmake to think they were the same file in some cases. - Fix issue with .lib being seen as .obj with VS due to a full path to a library given without the file extension. This only worked with the VS generator, but some projects had worked around it with if statements. It now issues a warning, but should link. - Update cpack stuff for beta OSX bundle generator for CPack - CheckFortranFunctionExists.cmake now calls the function. - FindBLAS.cmake, FindLAPACK.cmake modules were redesigned so now you have three new variables BLA_VENDOR (you can specify the VENDOR), BLA_STATIC (gets the static version of libs), BLA_F95 (gets the fortran 95 interface). BLA_VENDOR can be specified as an environment variable. Intel mkls libs need FindThreads to be found correctly so you will need to enable the C/CXX - FindMPI: Use the HINTS feature of find_library to find the right libraries for MPI, and act a bit more intelligently when MPI cannot be found. - Improved support for finding wxWidgets in MinGW environment. - CMAKE[_SYSTEM]_(LIBRARY|PROGRAM|INCLUDE|PREFIX)_PATH variables moved CMAKE_CROSSCOMPILING from "Variables that modify behaviour" to "variables that Provide Information" - handle HTML documentation for single items better: no warning about ComputeSectionLinkPrefix, don't create an index for only one item. - Better error messages in CPackBundleGenerator Changes in CMake 2.6.1 RC 11 - Fix curl build issue with Xcode 3.1 Changes in CMake 2.6.1 RC 10 - Add a fix for bug # 7340, CMAKE_USER_MAKE_RULES_OVERRIDE was not able to support a try-compile in cmake 2.6 - Remove bad test for bug # 7316 Changes in CMake 2.6.1 RC 9 - Fix bug # 7316 Xcode double escaped define strings - FindBoost can now find the upcoming Boost 1.36 Changes in CMake 2.6.1 RC 8 - Fix build problem with missing cpack file Changes in CMake 2.6.1 RC 7 - More fixes for CPack components functionality - Fixes for Xcode generater #7277 #7044, do not compile foo.txt. Rebuild application bundles when a library changes. Set the project location for Xcode 3.1 - Do not automatically add EXECUTABLE_OUTPUT_PATH to cache. - New tree view in cmake-gui - FindBoost.cmake, find boost as installed by the BoostPro/Boost Consulting installers on Windows. And cleanup FindBoost module, fixing several small bugs and providing better diagnostic information when things go wrong. - Fix FindwxWidgets.cmake to find richtext library - Fix FindQt4.cmake with empty qconfig.pri files. Fixes #7287. - Fix add/remove program version string again... - Fix column width in cmake-gui Changes in CMake 2.6.1 RC 6 - Fix DEFINITIONS property to be compatible with 2.4 - Fix escaping of $ for visual studio - FindGettext.cmake fix bug #7230: don't ignore first parameter if it's not ALL Changes in CMake 2.6.1 RC 5 - Add support for component based packages in cpack. - Fix FindBLAS.cmake if no fortran compiler is found - Fix FindFLTK.cmake to pass new module test - Fix FindKDE3.cmake to not add flags if kde3 is not found - Fix FindMatlab.cmake, FindOpenSSL.cmake, FindQt3.cmake, FindSWIG.cmake, to only error if it is required - Fix FindwxWidgets.cmake to work on msys - Add a beta OSX bundle generator for CPack - Fix bug in cmake --build-and-test where cmake output was lost - Fix ctest handling of CDash dart measurement support - Add a group view to cmake-gui - Fix nmake/make with visual studio compiler to handle long link lines - Fix FLTK_WRAP_UI to better notice when mistakes are made with the target name - Fix spelling error EnableFiberSafeOptimizations Changes in CMake 2.6.1 RC 4 - Change to find_*, a new HINTS keyword was added to avoid the need for NO_DEFAULT_PATH, and a repeated call to find_* - Update all NO_DEFAULT_PATH usage in Modules/Find* - Fix for cpack self extracting .sh files to work with more shells - FindQt4 now finds dependencies for some qt modules - ctest cpu information fixes for cygwin and linux - Recognize more color terminals for color output - Remove SKIP_RULE_DEPENDS from custom command because CMake now can detect when a cutom command actually changes and only re-run the rule then. This fixes the problem of custom commands re-running every time a file is added to a target. - Fix for very slow find_path on OSX because of framework searchs - Fix for bug 6364, extra help targets when there are subdirectories of the top level. - Fix for Xcode generator to not eat some flags by mistake. - Add end of file checking for close if, foreach, macro, functions etc enabled. Changes in CMake 2.6.1 RC 3 - FindQt4 - Find qt debug libraries on windows with d postfix. - Find 64 bit windows registry stuff with 32 bit cmake - Give a message if rpath is changed during install - rpath changer during install understands symlinks now - If a source file is not found and is a full path cmake complains. Changes in CMake 2.6.1 RC 2 - FindQt4 - report an error when trying to use MSVC with Qt built by mingw. - FindQt4 - make Qt not found if the QtCore library can't be found. - UseQt4 - only add flags for modles that are used - Log file and LC_ALL fix for FindSubversion - Make MacOSXBundleInfo.plist.in a configured file again - Fix makefile generator targets to depend on full path link libraries - Allow CMakeImportBuildSettings to not match tools if CMAKE_OVERRIDE_COMPILER_MISMATCH is set - Fix incorrect extension extraction in gcc cross compiler check - Add support for Portand Fortran - Fix list command with empty list values - Add support for setting compiler and toolchain in qt cmake-gui - Fix Bug 7011, FindQt4 was slow on a mac, find_path should not glob in / - Fix install directories for cygwin package of CMake Changes in CMake 2.6.1 RC 1 - Add a way to modify depend scanning with the property: IMPLICIT_DEPENDS_INCLUDE_TRANSFORM - Add a way for custom commands to skip depending on the rule.make file - Fix ENABLE_LANGUAGE(ASM-ATT OPTIONAL) to work - Fix gcov in ctest in French or other non-English runs - Fix help for ctest commands to be lower case - Find QtCLucene on Qt/Mac binary - Fix for build on ARM - Fix for docbook to add newlines - Fix -Wno-dev to not eat path to source tree - Fix bug in NSIS CPack where CPACK_NSIS_MODIFY_PATH did modify the path - Fix FindBoost version variable names to correct bug in Boost version - Fix Add/Remove program name for CMake install on windows - Fix bug 0006988 coverage not reported on dashboards - Fix bug 0006990 CMake crashes with bad input to set_source_files_properties - Fix bug in FindCurses where you could not run cmake twice - Fix 64 bit cmake creation of Xcode projects - Add --help-policy to --help Changes in CMake 2.6.0 - Fix links in generated documentation - Fix for FindQt and some mac frameworks - Fix for ctest to report more than 2 gigs system memory on windows - Fix CTest build name for vs 9, and fix memory size on windows Changes in CMake 2.6.0 RC 10 - Do not duplicate .so libraries on the link line - Add more system library paths to sun builds - Add BETA support for Intel Fortran IDE files in visual studio - Fix FindCurses to work if ncurses is the only option - Fix shell escapes on some systems - Remove check for file write as input to cmake, as it is no longer needed - Make check_type_size automatically check for headers that it uses - Remove minimum required from FindBoost.cmake - Fix FindSDL so that it can be run more than once - Fix find required for VTK package - Allow for CMAKE_OSX_SYSROOT to work with single architecture - Add context information when a source file cannot be found. - Report the directory-level context even if no list file is currently being processed. Changes in CMake 2.6.0 RC 9 - Fix for fortran mod:: support - Fix bug in install command with BUNDLE DESTINATION - Make mac install symlinks check for errors - Fix for CMP0007, to not warn about empty lists - Preserve static libraries when linked multiple times - Use c compiler path to find asm compiler - Allow RC compiler to not get all COMPILE_FLAGS - Complete overhaul for FindBoost.cmake - Minor fixes for FindMPI.cmake - Fix for list command and empty list elements CMP0007 - Fix for VS6 and sub-groups - Fix bug 6440, and make sure _INIT flags do not overright cache values - Do not report CMP0003 for anything other than -l - Fix crash in fortran depend scanning, bug 6855 - Fix timeout values for cmake's own tests - Better message in compiler ABI detect - Fixes for cpack x11 packages on leopard - Changes to cpack options names - Fixes for FindMPI on 64 bit MS MPI - Fix for -isystem for wxWidgets - Some fixes for chrpath during installation - Fix compatibility with CMake 2.4 for installation of MACOSX_BUNDLE (CMP0006) - Do not use debug postfix when building frameworks on the Mac - Fix exception handling off/on issue with visual studio IDE generators - Fix to be native path style - Fix leak in cpack - Some Qt GUI style changes Changes in CMake 2.6.0 RC 8 - Fix sun make very poor performance - Fix includes for automoc in FindQt4 Changes in CMake 2.6.0 RC 7 - Fix for chrpath on sun with gcc - Fix FindJNI on unix with HKEY issue bug 6688 - Change install location on mac for cmake-gui - Fix for bugs 6730 and 6720 in FindQt4 configured headers in binary dir - Add VS9 support to InstallRequiredSystemLibraries.cmake - Fix some bugs in framework support - Have make edit_cache work with cmake-gui and eclipse generator - Fix find_* to not mistakenly construct network paths on windows - Several bug fixes in cmake-gui Qt program. Changes in CMake 2.6.0 RC 6 - Added ChangeLog.manual - Allow CMakeImportBuildSettings force compiler to be optional - Change cpack deb packager to detect the architecture - Fix FindCurses to be backwards compatible with cache variable CURSES_LIBRARY - Add version variables to FindQt4.cmake - Fix CPack Deb generator to not hard code /usr - Better default size for cmake-gui help dialog - Fix problem where incorrect path was used for cmake.exe when used to do incremental linking on windows nmake or make - Fix build with system libraries on - Add color output in kdevelop - Create non-verbose makefiles in kdevelop - Fix some missing flags for vs IDE flag map - Fix MacOSX install symlink crash problem - Fix turning of Dev warnings with gui's - Fix backwards compatibility issue with FindMPI.cmake - Fix for bug 6605, add -L path for optimized in debug sometimes for backwards compatibility - Allow for CMP0000 to be set before any warnings happen - Do not use FAT32 hack in VS 2005 and 2008 unless on a FAT32 disk, causes try-compiles to be 3 times slower if FAT hack is present. - Fixes to debian cpack - Can now check if a proprty is SET or not - Fix for generate with vs 2005 and vista not being able to create stamp file - set_property with an empty value unsets that property now - Fix FindQt4 on windows with some \ style paths Changes in CMake 2.6.0 - Documentation for all variables - Automatic reload of projects in visual stuido 7 and greater when cmake is re-run. - Direct CDash submit support - Bullseye coverage support - Use full paths for linking to libraries on all platforms. No longer separate into -L and -l. - Enhance the install command - export command and ability to have imported targets - CPack support for rpm and deb - Cross compile support - New Qt GUI - Introduction of the cmake_policy command - Much better Fortran support - Mac OSX Framework creation support - Project generators for Eclipse and CodeBlocks - Beta support for asm in makefiles - Enhanced find_package() command with support for project-installed FooConfig.cmake files - New CMAKE_PREFIX_PATH environment variable to specify user search dirs for find_xxx() - Lots of bug fixes From robla at lindenlab.com Fri Sep 26 12:57:13 2008 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Sep 26 12:57:16 2008 Subject: [sldev] CMake 2.6.2 available for download In-Reply-To: <48DD28B9.90804@kitware.com> References: <48DD28B9.90804@kitware.com> Message-ID: <48DD3E99.7050306@lindenlab.com> Hi Bill, Thanks for being so attentive and tailoring so much of this release around the needs of this project! Your attention to detail and responsiveness here has confirmed that we made the right choice moving to CMake. Rob On 9/26/08 11:23 AM, Bill Hoffman wrote: > On behalf of myself, Ken, Brad, Dave, Alex and the rest of the > CMake team, we are pleased to announce that CMake 2.6.2 is > available for download at: > > http://www.cmake.org/cmake/resources/software.html > > If you have any problems or find any bugs, please report them at > www.cmake.org/Bug. From ramzi at lindenlab.com Fri Sep 26 13:11:03 2008 From: ramzi at lindenlab.com (Ramzi) Date: Fri Sep 26 13:11:06 2008 Subject: [sldev] Security Update to SL Viewers and source code Message-ID: <48DD41D7.2000009@lindenlab.com> Hi SLDEVelopers, I wanted to mention directly to the SLDEV list that Linden Lab released a security update to the official and Release Candidate viewers to address a potential security issue. Updated source code is available at: http://wiki.secondlife.com/wiki/Source_downloads The full text of the announcement to Second Life Residents is on the Status Page of secondlifegrid.net, and repeated here below for your convenience. Kind regards, Ramzi Linden http://status.secondlifegrid.net/2008/09/26/post256/ *Security Update to Second Life viewers: 26 Sept 2008* Linden Lab has released an optional update to the Second Life viewers today to address a potential security issue. Recently an audit identified a possible vulnerability. If a malicious user were able to obtain the IP address and port of a Resident?s viewer, then the malicious user could forge data packets to the Resident?s computer. This could be done in a way to cause the viewer to return enough information about its session to allow the attacker to initiate various server-side operations as if they were the Resident, including L$ transactions. In the case of L$ transactions, this action would be visible to you: if this were to occur, the viewer would report the transaction after it occurred in the normal blue dialog box. Also, you are always able to inspect the transaction log to see recent transactions. This would allow you to notice and report these actions for violating the Second Life Terms of Service. This type of malicious action would constitute a violation of the Terms of Service, and would be against the law in some locations. At this time we have no evidence that this vulnerability was ever exploited. To eliminate this vulnerability, we have now updated the Second Life servers to transmit the messages over an encrypted channel (HTTPS). Now that the server upgrade is complete, we are releasing updated viewers that only accept these messages when transmitted over an encrypted channel. Once you have downloaded the update, if a malicious third party were to attempt to send messages over the old channel (UDP), they would be ignored. Again, we have no indication to date that this security issue has ever been exploited or is being exploited currently. However, we strongly encourage Second Life Residents to update to the latest viewer with the security patches in place. The viewers are: * Second Life Release Viewer 1.20.16 (this updates 1.20.15, released on July 24th) * Second Life Release Candidate Viewer 1.21 RC3 (this updates RC2 and includes additional bug fixes as part of the usual release candidate cycle) Older viewers (such as the 1.19 series) are not being required to upgrade to version 1.20.16, but we encourage Residents to update if possible to take advantage of the latest bug and security fixes. The updated source code for these new 1.20 and 1.21 RC viewers is being made available via the usual open source channels. For discussion about the issue, please visit the Second Life Forum: http://forums.secondlife.com/forumdisplay.php?f=350 From whump at lindenlab.com Fri Sep 26 17:35:48 2008 From: whump at lindenlab.com (Bill Humphries) Date: Fri Sep 26 17:35:51 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: References: Message-ID: Suzy, Dr. Scofield: Thank you for bringing the issue with compiling scripts with OpenSim- specific extensions to LSL to our attention. It's not our intention to 'break the viewer' with the recent changes, as a viewer fork would not be in the interests of grid interoperability. However, the change was made for a reason, and I need some time to figure out why it was made. Thanks for your patience. We are looking at the JIRA Suzy filed, http://jira.secondlife.com/browse/VWR-9332 . Thank you. -- whump On Sep 26, 2008, at 5:23 AM, Suzy Deffeyes wrote: > I think it is really helpful to have a common viewer for the OpenGrid > work, at least in the short term. Once OpenSim developers switch to > another viewer, the desire to maintain protocol compatibility with > Second > Life becomes much less compelling. > > I did some digging into the viewer on this issue, and opened a jira > for > it. > > http://jira.secondlife.com/browse/VWR-9332 > > OpenSim needs a way to pass OS*() functions in scripts back to the > sim. > > > Note also that there appears to be a recent addition to the protocol > for > ScriptRunningReply, a bool named 'Mono' is now checked by the > viewer. I > opened a Mantis bug for this: > > http://opensimulator.org/mantis/view.php?id=2270 > > > Thanks > Suzy Deffeyes > Virtual Worlds > Digital Convergence EBO > IBM Research > 512.838.8770 > suzyq@us.ibm.com > > > gridnauts-bounces@lists.secondlife.com wrote on 09/26/2008 03:41:32 > AM: > >> having just wasted most of a day on trying to figure out why OSSL >> functions such as osSetDynamicTextureData and friends were >> returning an >> LSL compile error (ERROR: name not in scope) i thought i'd report >> back >> on my findings: >> >> * OSSL functions (inspite of the heavy changes in the scripting >> subsystem in recent days) are working just fine (provided you >> enabled them as documented in OpenSim.ini.example) >> * recent LindenLab(tm)/(r) provided secondlife clients (certainly >> the 1.21 series) are apparently no longer relying on the grid to >> vet the script and the functions it calls, but instead seem to >> check all function calls against >> o list of known LSL function >> o list of functions you have defined in your script >> o anything not found on those lists is flagged as "not in > scope" >> >> once i switched to hippo viewer >> (http://forge.opensimulator.org/gf/project/opensim-viewer/) >> >> everything >> was fine. >> >> cheers, >> dr scofield >> >> -- >> dr dirk husemann ---- virtual worlds research ---- ibm zurich >> research > lab >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- > http://xyzzyxyzzy.net/ >> RL: hud@zurich.ibm.com - +41 44 724 8573 - > http://www.zurich.ibm.com/~hud/ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts Whump Linden is Bill Humphries || whump@lindenlab.com || http://secondlife.com/ From jjustincc at googlemail.com Sat Sep 27 03:44:10 2008 From: jjustincc at googlemail.com (Justin Clark-Casey) Date: Sat Sep 27 03:44:17 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions Message-ID: <48DE0E7A.1000504@googlemail.com> To be honest, I think that things should go further than this. People running OpenSim environments may well want to implement LSL functions themselves server-side which do not start with either the ll or os prefixes. Suzy Deffeyes wrote: > > Thanks, Whump. I appreciate you looking into this so quickly. > > There are 30-ish functions in OpenSim's scripting with the os prefix. > If we could have a way to ensure that any function with the os prefix > in its name could be passed to the sim, that would work. > > Thanks > Suzy Deffeyes > Virtual Worlds > Digital Convergence EBO > IBM Research > 512.838.8770 > suzyq@us.ibm.com > > > Bill Humphries wrote on 09/26/2008 07:35:48 PM: > > > Suzy, Dr. Scofield: > > > > Thank you for bringing the issue with compiling scripts with OpenSim- > > specific extensions to LSL to our attention. > > > > It's not our intention to 'break the viewer' with the recent changes, > > as a viewer fork would not be in the interests of grid interoperability. > > > > However, the change was made for a reason, and I need some time to > > figure out why it was made. Thanks for your patience. > > > > We are looking at the JIRA Suzy filed, http://jira.secondlife. > > com/browse/VWR-9332 > > . > > > > Thank you. > > > > -- whump > > > > On Sep 26, 2008, at 5:23 AM, Suzy Deffeyes wrote: > > > > > I think it is really helpful to have a common viewer for the OpenGrid > > > work, at least in the short term. Once OpenSim developers switch to > > > another viewer, the desire to maintain protocol compatibility with > > > Second > > > Life becomes much less compelling. > > > > > > I did some digging into the viewer on this issue, and opened a jira > > > for > > > it. > > > > > > http://jira.secondlife.com/browse/VWR-9332 > > > > > > OpenSim needs a way to pass OS*() functions in scripts back to the > > > sim. > > > > > > > > > Note also that there appears to be a recent addition to the protocol > > > for > > > ScriptRunningReply, a bool named 'Mono' is now checked by the > > > viewer. I > > > opened a Mantis bug for this: > > > > > > http://opensimulator.org/mantis/view.php?id=2270 > > > > > > > > > Thanks > > > Suzy Deffeyes > > > Virtual Worlds > > > Digital Convergence EBO > > > IBM Research > > > 512.838.8770 > > > suzyq@us.ibm.com > > > > > > > > > gridnauts-bounces@lists.secondlife.com wrote on 09/26/2008 03:41:32 > > > AM: > > > > > >> having just wasted most of a day on trying to figure out why OSSL > > >> functions such as osSetDynamicTextureData and friends were > > >> returning an > > >> LSL compile error (ERROR: name not in scope) i thought i'd report > > >> back > > >> on my findings: > > >> > > >> * OSSL functions (inspite of the heavy changes in the scripting > > >> subsystem in recent days) are working just fine (provided you > > >> enabled them as documented in OpenSim.ini.example) > > >> * recent LindenLab(tm)/(r) provided secondlife clients (certainly > > >> the 1.21 series) are apparently no longer relying on the grid to > > >> vet the script and the functions it calls, but instead seem to > > >> check all function calls against > > >> o list of known LSL function > > >> o list of functions you have defined in your script > > >> o anything not found on those lists is flagged as "not in > > > scope" > > >> > > >> once i switched to hippo viewer > > >> (http://forge.opensimulator.org/gf/project/opensim-viewer/) > > >> > > >> everything > > >> was fine. > > >> > > >> cheers, > > >> dr scofield > > >> > > >> -- > > >> dr dirk husemann ---- virtual worlds research ---- ibm zurich > > >> research > > > lab > > >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- > > > http://xyzzyxyzzy.net/ > > >> RL: hud@zurich.ibm.com - +41 44 724 8573 - > > > http://www.zurich.ibm.com/~hud/ > > >> > > >> _______________________________________________ > > >> Click here to unsubscribe or manage your list subscription: > > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts > > > > Whump Linden is Bill Humphries || whump@lindenlab.com || http: > > //secondlife.com/ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts -- justincc Justin Clark-Casey http://justincc.wordpress.com From suzyque at gmail.com Sat Sep 27 06:30:08 2008 From: suzyque at gmail.com (Suzy Deffeyes) Date: Sat Sep 27 06:30:51 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: <48DE0E7A.1000504@googlemail.com> References: <48DE0E7A.1000504@googlemail.com> Message-ID: Hi Justin, I was trying to suggest some middle ground between the desire to have nice tight type checking in the viewer script compilation code and the desire to have wide open naming. I was also wanting someone from Linden to look at it soon since my brain was scrambled after looking into it a bit. The compilation code is hairy. Suzy Sent from my iPhone On Sep 27, 2008, at 5:44 AM, Justin Clark-Casey wrote: > To be honest, I think that things should go further than this. > People running OpenSim environments may well want to > implement LSL functions themselves server-side which do not start > with either the ll or os prefixes. > > Suzy Deffeyes wrote: >> Thanks, Whump. I appreciate you looking into this so quickly. >> There are 30-ish functions in OpenSim's scripting with the os >> prefix. If we could have a way to ensure that any function with >> the os prefix in its name could be passed to the sim, that would >> work. >> Thanks >> Suzy Deffeyes >> Virtual Worlds >> Digital Convergence EBO >> IBM Research >> 512.838.8770 >> suzyq@us.ibm.com >> Bill Humphries wrote on 09/26/2008 07:35:48 PM: >> > Suzy, Dr. Scofield: >> > >> > Thank you for bringing the issue with compiling scripts with >> OpenSim- >> > specific extensions to LSL to our attention. >> > >> > It's not our intention to 'break the viewer' with the recent >> changes, > as a viewer fork would not be in the interests of grid >> interoperability. >> > >> > However, the change was made for a reason, and I need some time >> to > figure out why it was made. Thanks for your patience. >> > >> > We are looking at the JIRA Suzy filed, http://jira.secondlife. >> > com/browse/VWR-9332 >> > . >> > >> > Thank you. >> > >> > -- whump >> > >> > On Sep 26, 2008, at 5:23 AM, Suzy Deffeyes wrote: >> > >> > > I think it is really helpful to have a common viewer for the >> OpenGrid >> > > work, at least in the short term. Once OpenSim developers >> switch to >> > > another viewer, the desire to maintain protocol compatibility >> with > > Second >> > > Life becomes much less compelling. >> > > >> > > I did some digging into the viewer on this issue, and opened a >> jira > > for >> > > it. >> > > >> > > http://jira.secondlife.com/browse/VWR-9332 >> > > >> > > OpenSim needs a way to pass OS*() functions in scripts back to >> the > > sim. >> > > >> > > >> > > Note also that there appears to be a recent addition to the >> protocol > > for >> > > ScriptRunningReply, a bool named 'Mono' is now checked by the >> > > viewer. I >> > > opened a Mantis bug for this: >> > > >> > > http://opensimulator.org/mantis/view.php?id=2270 >> > > >> > > >> > > Thanks >> > > Suzy Deffeyes >> > > Virtual Worlds >> > > Digital Convergence EBO >> > > IBM Research >> > > 512.838.8770 >> > > suzyq@us.ibm.com >> > > >> > > >> > > gridnauts-bounces@lists.secondlife.com wrote on 09/26/2008 >> 03:41:32 > > AM: >> > > >> > >> having just wasted most of a day on trying to figure out why >> OSSL >> > >> functions such as osSetDynamicTextureData and friends were > >> >> returning an >> > >> LSL compile error (ERROR: name not in scope) i thought i'd >> report > >> back >> > >> on my findings: >> > >> >> > >> * OSSL functions (inspite of the heavy changes in the >> scripting >> > >> subsystem in recent days) are working just fine (provided >> you >> > >> enabled them as documented in OpenSim.ini.example) >> > >> * recent LindenLab(tm)/(r) provided secondlife clients >> (certainly >> > >> the 1.21 series) are apparently no longer relying on the >> grid to >> > >> vet the script and the functions it calls, but instead >> seem to >> > >> check all function calls against >> > >> o list of known LSL function >> > >> o list of functions you have defined in your script >> > >> o anything not found on those lists is flagged as >> "not in >> > > scope" >> > >> >> > >> once i switched to hippo viewer >> > >> (http://forge.opensimulator.org/gf/project/opensim-viewer/) >> > >> >> > >> everything >> > >> was fine. >> > >> >> > >> cheers, >> > >> dr scofield >> > >> >> > >> -- >> > >> dr dirk husemann ---- virtual worlds research ---- ibm >> zurich > >> research >> > > lab >> > >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- >> > > http://xyzzyxyzzy.net/ >> > >> RL: hud@zurich.ibm.com - +41 44 724 8573 - >> > > http://www.zurich.ibm.com/~hud/ >> > >> >> > >> _______________________________________________ >> > >> Click here to unsubscribe or manage your list subscription: >> > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts >> > > _______________________________________________ >> > > Click here to unsubscribe or manage your list subscription: >> > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts >> > >> > Whump Linden is Bill Humphries || whump@lindenlab.com || http: >> > //secondlife.com/ >> > >> --- >> --------------------------------------------------------------------- >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/gridnauts > > > -- > justincc > Justin Clark-Casey > http://justincc.wordpress.com > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From sldev at free.fr Sat Sep 27 07:12:32 2008 From: sldev at free.fr (Henri Beauchamp) Date: Sat Sep 27 07:12:36 2008 Subject: [sldev] Security Update to SL Viewers and source code In-Reply-To: <48DD41D7.2000009@lindenlab.com> References: <48DD41D7.2000009@lindenlab.com> Message-ID: <20080927161232.2b1955d2.sldev@free.fr> On Fri, 26 Sep 2008 13:11:03 -0700, Ramzi wrote: > .../... However, we strongly > encourage Second Life Residents to update to the latest viewer with the > security patches in place. The viewers are: > > * Second Life Release Viewer 1.20.16 (this updates 1.20.15, released on > July 24th) > * Second Life Release Candidate Viewer 1.21 RC3 (this updates RC2 and > includes additional bug fixes as part of the usual release candidate cycle) > > Older viewers (such as the 1.19 series) are not being required to > upgrade to version 1.20.16, but we encourage Residents to update if > possible to take advantage of the latest bug and security fixes. What about residents with "old" computers and who can't run v1.20+ with decent frame rate ?... Well, I backported the fix to v1.19.0.5, and I use it in the corresponding version of the Cool SL Viewer (http://sldev.free.fr/). The patch is avialable here: http://sldev.free.fr/patches/11905/slviewer-0-v11905-SecurityFixBackport.patch.bz2 Henri. From secret.argent at gmail.com Sat Sep 27 07:46:00 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 27 07:46:01 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: <48DE0E7A.1000504@googlemail.com> References: <48DE0E7A.1000504@googlemail.com> Message-ID: <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> * recent LindenLab(tm)/(r) provided secondlife clients (certainly the 1.21 series) are apparently no longer relying on the grid to vet the script and the functions it calls, but instead seem to check all function calls against o list of known LSL function o list of functions you have defined in your script o anything not found on those lists is flagged as "not in scope" The script editor has ALWAYS handled the compilation and syntax checking, see indra.l and indra.y. This was never done by the server UNTIL 1.21. From secret.argent at gmail.com Sat Sep 27 07:48:45 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 27 07:48:46 2008 Subject: [sldev] Security Update to SL Viewers and source code In-Reply-To: <20080927161232.2b1955d2.sldev@free.fr> References: <48DD41D7.2000009@lindenlab.com> <20080927161232.2b1955d2.sldev@free.fr> Message-ID: <64E2E8E7-EFCC-48E1-AA09-0CD62EEB1260@gmail.com> On 2008-09-27, at 09:12, Henri Beauchamp wrote: > Well, I backported the fix to v1.19.0.5, and I use it in the > corresponding version of the Cool SL Viewer (http:// > sldev.free.fr/). The patch is avialable here: I really think LL needs to release a "postultimate" 1.19 viewer with the Havok4 altitude fixes and this security patch. Or else go back to the drawing board, REALLY figure out how to make 1.20 run well on older computers, and pull 1.19. From drscofield at xyzzyxyzzy.net Sat Sep 27 08:09:28 2008 From: drscofield at xyzzyxyzzy.net (dr scofield) Date: Sat Sep 27 08:09:36 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> References: <48DE0E7A.1000504@googlemail.com> <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> Message-ID: <48DE4CA8.3000803@xyzzyxyzzy.net> Argent Stonecutter wrote: > * recent LindenLab(tm)/(r) provided secondlife clients (certainly > the 1.21 series) are apparently no longer relying on the grid to > vet the script and the functions it calls, but instead seem to > check all function calls against > o list of known LSL function > o list of functions you have defined in your script > o anything not found on those lists is flagged as "not in > scope" > > The script editor has ALWAYS handled the compilation and syntax > checking, see indra.l and indra.y. This was never done by the server > UNTIL 1.21. but apparently it now is flagging os* functions. which goes beyond compilation and syntax checking, it's kind of like tentative linking... -- dr dirk husemann ---- math & computer science ---- ibm zurich research lab RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ SL: drscofield@xyzzyxyzzy.net --------------------- http://xyzzyxyzzy.net/ From secret.argent at gmail.com Sat Sep 27 08:22:17 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Sep 27 08:22:17 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: <48DE4CA8.3000803@xyzzyxyzzy.net> References: <48DE0E7A.1000504@googlemail.com> <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> <48DE4CA8.3000803@xyzzyxyzzy.net> Message-ID: <55E2C86C-49E8-40D8-A41C-8225968FCE9F@gmail.com> On 2008-09-27, at 10:09, dr scofield wrote: > but apparently it now is flagging os* functions. which goes beyond > compilation and syntax checking, it's kind of like tentative > linking... Look at the source code. The functions have always been hardcoded in the compiler in the client. You must have been doing something to suppress compilation before 1.21, because it has always rejected scripts with undefined functions when they were compiled. From suzyque at gmail.com Sat Sep 27 12:02:20 2008 From: suzyque at gmail.com (Suzy Deffeyes) Date: Sat Sep 27 12:04:20 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: <55E2C86C-49E8-40D8-A41C-8225968FCE9F@gmail.com> References: <48DE0E7A.1000504@googlemail.com> <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> <48DE4CA8.3000803@xyzzyxyzzy.net> <55E2C86C-49E8-40D8-A41C-8225968FCE9F@gmail.com> Message-ID: Dr Sco is an OpenSim dev, so he tends to not look at the GPL viewer code. :-) I was trying to sift thru the changes in the script compiler code, and it did look like it *should* have always failed. I know the OS functions used to work ( with no viewer code changes or setting anything in the environment to indicate different handling in the script compiler ). So I was puzzled and thus the jira bug. Suzy Sent from my iPhone On Sep 27, 2008, at 10:22 AM, Argent Stonecutter wrote: > On 2008-09-27, at 10:09, dr scofield wrote: >> but apparently it now is flagging os* functions. which goes beyond >> compilation and syntax checking, it's kind of like tentative >> linking... > > Look at the source code. The functions have always been hardcoded in > the compiler in the client. You must have been doing something to > suppress compilation before 1.21, because it has always rejected > scripts with undefined functions when they were compiled. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From sly_squash at hotmail.com Sun Sep 28 01:37:32 2008 From: sly_squash at hotmail.com (Joshy Squashy) Date: Sun Sep 28 01:37:34 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? Message-ID: Hello, I do some work that interfaces virtual objects in a second life environment with external systems (or even just custom SL viewers). I typically interact with those objects through the fairly-crippled XML-RPC interface, where objects are "stunned" for several seconds after processing a single xml-rpc event, objects can't "call out" to external systems, and objects must communicate in short messages. With the Mono update, I was hoping for the capacity to use mono frameworks (specifically Sockets) in the virtual object's mono code, but upon using the RC viewer I can't find any language differences or enhancements. I think its fair to say this conversion to Mono is very much "under the hood"; however, as scripts run so much faster I was wondering what xml-rpc limitations still exist in Mono scripts. If the answer is "all of them", I was wondering if there were plans to expand the xml-rpc interface or to use mono syntax/libraries. ~Squash Otoro _________________________________________________________________ See how Windows Mobile brings your life together?at home, work, or on the go. http://clk.atdmt.com/MRT/go/msnnkwxp1020093182mrt/direct/01/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080928/948e5088/attachment.htm From me at signpostmarv.name Sun Sep 28 01:50:34 2008 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun Sep 28 01:50:41 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: References: Message-ID: <48DF455A.8060609@signpostmarv.name> Last I checked, the plan was to phase out XML-RPC in favour of plain old HTTP. ~ Marv. Joshy Squashy wrote: > Hello, > > I do some work that interfaces virtual objects in a second life > environment with external systems (or even just custom SL viewers). I > typically interact with those objects through the fairly-crippled > XML-RPC interface, where objects are "stunned" for several seconds > after processing a single xml-rpc event, objects can't "call out" to > external systems, and objects must communicate in short messages. > With the Mono update, I was hoping for the capacity to use mono > frameworks (specifically Sockets) in the virtual object's mono code, > but upon using the RC viewer I can't find any language differences or > enhancements. > > I think its fair to say this conversion to Mono is very much "under > the hood"; however, as scripts run so much faster I was wondering what > xml-rpc limitations still exist in Mono scripts. If the answer is > "all of them", I was wondering if there were plans to expand the > xml-rpc interface or to use mono syntax/libraries. > > ~Squash Otoro > > ------------------------------------------------------------------------ > See how Windows Mobile brings your life together?at home, work, or on > the go. See Now > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080928/0e79f583/smime.bin From secret.argent at gmail.com Sun Sep 28 04:09:42 2008 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Sep 28 04:09:46 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: References: Message-ID: On 2008-09-28, at 03:37, Joshy Squashy wrote: > I think its fair to say this conversion to Mono is very much "under > the hood"; however, as scripts run so much faster I was wondering > what xml-rpc limitations still exist in Mono scripts. If the > answer is "all of them", I was wondering if there were plans to > expand the xml-rpc interface or to use mono syntax/libraries. There have been a number of comments from Linden Labs indicating that there are no current plans for adding direct access to any Mono libraries or languages. From lenglish5 at cox.net Sun Sep 28 07:33:22 2008 From: lenglish5 at cox.net (Lawson English) Date: Sun Sep 28 07:33:50 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: References: Message-ID: <48DF95B2.8030504@cox.net> Argent Stonecutter wrote: > On 2008-09-28, at 03:37, Joshy Squashy wrote: >> I think its fair to say this conversion to Mono is very much "under >> the hood"; however, as scripts run so much faster I was wondering >> what xml-rpc limitations still exist in Mono scripts. If the answer >> is "all of them", I was wondering if there were plans to expand the >> xml-rpc interface or to use mono syntax/libraries. > > > There have been a number of comments from Linden Labs indicating that > there are no current plans for adding direct access to any Mono > libraries or languages. > From what Ted Maa has said to me, it appears that one LL long-term goal is to get scripting in SL compatible with new OSS features and capabilities, so you can get some idea of one direction SL scripting will go in by looking at where OpenSim Scripting is heading. Of course, the opposite is also true: new LL innovations will obviously copied by OpenSim as well: http://opensimulator.org/wiki/Scripting_Documentation Lawson From GordonWendt at gmail.com Sun Sep 28 11:28:44 2008 From: GordonWendt at gmail.com (Gordon Wendt) Date: Sun Sep 28 11:28:48 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: <48DF455A.8060609@signpostmarv.name> References: <48DF455A.8060609@signpostmarv.name> Message-ID: <493033a70809281128ie11c4adpd0a3d452d77b4f0@mail.gmail.com> On Sun, Sep 28, 2008 at 4:50 AM, SignpostMarv Martin wrote: > Last I checked, the plan was to phase out XML-RPC in favour of plain old > HTTP. > > ~ Marv. > And yet it still isn't possible to authenticate to a server which I think is what many scripers have wanted to be able to do for quite some time to access secured resources in a secure manner and which has been summarily ignored by LL. -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080928/41fc12c5/attachment.htm From jhurliman at jhurliman.org Sun Sep 28 12:59:16 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sun Sep 28 12:59:19 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: References: <48DE0E7A.1000504@googlemail.com> <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> <48DE4CA8.3000803@xyzzyxyzzy.net> <55E2C86C-49E8-40D8-A41C-8225968FCE9F@gmail.com> Message-ID: It did always fail in the past. However, even when a script compile fails the source code is still uploaded to the server, so OpenSim would attempt server-side compilation and ignore any bytecode sent from the client. This sounds like things are reverting back to how it used to be. John On Sat, Sep 27, 2008 at 8:02 PM, Suzy Deffeyes wrote: > Dr Sco is an OpenSim dev, so he tends to not look at the GPL viewer code. > :-) > > I was trying to sift thru the changes in the script compiler code, and it > did look like it *should* have always failed. I know the OS functions used > to work ( with no viewer code changes or setting anything in the environment > to indicate different handling in the script compiler ). > > So I was puzzled and thus the jira bug. > Suzy > > Sent from my iPhone > > On Sep 27, 2008, at 10:22 AM, Argent Stonecutter > wrote: > > On 2008-09-27, at 10:09, dr scofield wrote: >> >>> but apparently it now is flagging os* functions. which goes beyond >>> compilation and syntax checking, it's kind of like tentative linking... >>> >> >> Look at the source code. The functions have always been hardcoded in the >> compiler in the client. You must have been doing something to suppress >> compilation before 1.21, because it has always rejected scripts with >> undefined functions when they were compiled. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080928/5eaad083/attachment.htm From jhurliman at jhurliman.org Sun Sep 28 13:11:52 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sun Sep 28 13:11:57 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> Message-ID: Thank you for the info Teravus. It seems reasonable that -1 would be a default value that defaults to the lowest discard level available, or the previously set discard level if the client has already requested a specific one. I think the best approach at this point is going to be a libomv app to do lots of guess and check work. I'll post back when I find out more. John On Thu, Sep 25, 2008 at 7:40 PM, Teravus Ovares wrote: > Once again, I know this is speculation.. however I ran some tests > on this a few months back. I attempted to send the discard levels as > individual images, and the first discard level requested came through, > however, subsequent 'images' sent representing the next level of > discard level caused it to corrupt the image client side. This > leads me to believe that the discard levels represent byte offsets of > where the boundary between the packets that represent the discard > levels are.. as far as the server is concerned. So, in other > words.. lets say you have 5 discard levels in an image. > > You'd have to know this before hand in meta data or decode it on the fly. > > The client asks for discard level 5... We send it bytes 0-1000. > The client asks for discard level 3 of the same image.. we know it > has already received the discard level 5 bytes.. so we send bytes > 1001-5000. > > .. and we keep appending the rest of the file based on the packets > in the file > > This implies that the packets are ordered in sequence from lowest at > the beginning to highest at the end. > > Sometimes we get requests on the simulator for -1 before the rest of > the discard levels are requested. > > Sometimes we get requests on the simulator for -1 when the third > discard level is requested.. It seems to have to do with > defining and keeping image priority. > > On a Linden Simulator, it appears that there's an image priority queue > that it uses to feed the clients images at different discard levels > and keep track of the ones it has previously sent. It also seems to > reorder them in the priority 'list' that the server keeps. > > But!, it would be nice to get a LL Developer's view on what Discard > Level actually represents. > > Best Regards > > Teravus > > On 9/24/08, Salvador Agati wrote: > > > > > > > > ----- Original Message ----- > > From: John Hurliman > > To: Carsten Juttner > > Cc: Second Life Developer Mailing List > > Sent: Sunday, September 21, 2008 1:05 AM > > Subject: Re: [sldev] Meaning of RequestImage DiscardLevel field? > > > > > > Thank you Carsten, that clarification is correct. For now I'm assuming > that > > DiscardLevel 0 is a request for the full quality (zero discarded levels) > and > > DiscardLevel 5 is requesting the lowest quality level. However, if you > start > > with five quality layers and you discard five of them what are you left > > with? Is five actually being clamped to four? This still doesn't explain > -1. > > If you send a RequestImage with Priority = 0.0 and DiscardLevel = -1 it > will > > cancel the download, but texture requests often start with a positive > > priority and a DiscardLevel of -1. Is this a request for the header only, > or > > is it just an uninitialized value in the client that implies zero or > four? > > > > John > > > > > > On Fri, Sep 19, 2008 at 3:45 PM, Carsten Juttner wrote: > > > > > > > > > Robin Cornelius wrote: > > > > > > John Hurliman wrote: > > > > > > > I know that the DiscardLevel field in the RequestImage packet is used > > to > request different quality levels (not different texture sizes as > > the > protocol documentation states, SL uses LRCP ordered JPEG2000 files), > > but > i can't figure out what the values correspond to. In a typical > > texture > download I'll see values ranging from -1 to 5. Is -1 a special > > value? Is > there an upper limit? Does a larger number mean a lower quality > > layer? > > > > > The discard field is directly related to the request quality level as > you > > are already aware. It should be a simple calculation that the > discard is the > > number of powers of 2 to scale the image down by for the > reduced quality. So > > a discard of 0 is the complete image and a discard > of 1 is a 1/2 size, a > > discard of 2 is a 1/4 size etc. > > > > > > > I think what John was actually referring to here is that quality layers > > and resolution levels are not the same. In JPEG2k all data is divided > into > > packets for one tile. Each packet contains codestream data for one > quality > > layer for one resolution for one component for one precinct (spatial > > partition). The order in which you transmit the packets decides what you > get > > first and is signalled by the "progression order". LRCP > > (Layer-Resolution-Component-Position) is layer-centric > > meaning that one by one you get all the data for each quality layer, not > for > > each resolution. That means you end up with the lowest quality layer for > all > > resolutions first so it's really a quality-based progression, not a > > resolution-based. > > > > > > Think of the quality layers as going down the bits from MSB to LSB. > First > > you get the rough information, then it progresses to the detailed > > information (actually for the wavelet coefficients). > > > > > > AFAIK, inside the viewer the progression order is not really cared > about > > and the discard levels are merely referring to the dropped resolutions > from > > the highest resolution. > > > > > > Also nobody seems to really know what is happening on the server side > > since we did ask a while ago but never met a Linden who was familiar with > > that area of the code so it's still a bit of a mystery. > > > > > > Regards, > > > Carsten > > > > > > > > > > > > > > > I'm not used to post here and I' ve got only these 2 messages above > > related to the subject. Indeed , english is not my native language and I > am > > concious that I'm not an expert as you, in this list, are. > > > > > > Despite of that, I decided to send this post because one of the first > > things I noted when I began to discover SL was exactly the way images > were > > loaded in the viewer. > > > > > > It reminded me when I, after the college, was a mastering student and > had > > to read and discuss, in the class, the implementation of an algoritm . I > > happened at about 20 years ago. > > > > > > In this book, it was presented an algoritm called "gross information > > first" and it used in the formula, power of 2 numbers to calculate the > > pixel value of a group of pixels of a image. So, the quality of the > image > > generated with the algoritm was related to 2, 4, 8, 16, 32 or thinking as > > power of 2, the values 0,1,2,3,4,5 . > > > > > > I was wondering if this is the case, where the viewer asks for the next > > quality layer after the previous layer loaded and -1 to ask for data > without > > this type of filtering. > > > > > > In this situation, the image, in the server, would be stored only with > > the highest quality and the server would first "filter" the image, with > the > > correct factor, and then, send it to the viewer, progressively, as > > requested. > > > > > > If someone call me crazy , I won't deny. > > > > > > Regards, > > > Agathos Frascati SL > > > Salvador Agati RL > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080928/f69cca22/attachment.htm From nexeus at nexeusfatale.com Sun Sep 28 13:39:23 2008 From: nexeus at nexeusfatale.com (Nexeus Fatale) Date: Sun Sep 28 13:39:20 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: <48DF455A.8060609@signpostmarv.name> References: <48DF455A.8060609@signpostmarv.name> Message-ID: <48DFEB7B.50605@nexeusfatale.com> If I remember, this was what is going to replace xml-rpc http://wiki.secondlife.com/wiki/LSL_http_server - Nexeus SignpostMarv Martin wrote: > Last I checked, the plan was to phase out XML-RPC in favour of plain > old HTTP. > > ~ Marv. > > Joshy Squashy wrote: >> Hello, >> >> I do some work that interfaces virtual objects in a second life >> environment with external systems (or even just custom SL viewers). >> I typically interact with those objects through the fairly-crippled >> XML-RPC interface, where objects are "stunned" for several seconds >> after processing a single xml-rpc event, objects can't "call out" to >> external systems, and objects must communicate in short messages. >> With the Mono update, I was hoping for the capacity to use mono >> frameworks (specifically Sockets) in the virtual object's mono code, >> but upon using the RC viewer I can't find any language differences or >> enhancements. >> >> I think its fair to say this conversion to Mono is very much "under >> the hood"; however, as scripts run so much faster I was wondering >> what xml-rpc limitations still exist in Mono scripts. If the answer >> is "all of them", I was wondering if there were plans to expand the >> xml-rpc interface or to use mono syntax/libraries. >> >> ~Squash Otoro >> >> ------------------------------------------------------------------------ >> See how Windows Mobile brings your life together?at home, work, or on >> the go. See Now >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From carjay at gmx.net Sun Sep 28 14:45:45 2008 From: carjay at gmx.net (Carsten Juttner) Date: Sun Sep 28 14:45:43 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> Message-ID: <48DFFB09.80100@gmx.net> Teravus Ovares wrote: > The client asks for discard level 5... We send it bytes 0-1000. > The client asks for discard level 3 of the same image.. we know it > has already received the discard level 5 bytes.. so we send bytes > 1001-5000. > Interesting, that would indicate the discard level in the protocol is also used as a kind of bookkeeping on the server. Which makes no sense really since the client is the only one knowing for sure how many bytes it has already received. The only reason to state the discard levels in this way would be to make sure the client receives the necessary amount of data without having to parse the packets. Which leads to another interesting question: how do they determine the byte offsets? Are they guessed (there is a kind of 1/8th rule of thumb built into the client so it could be the same for the server) or based on the real packet boundaries in the codestream? > But!, it would be nice to get a LL Developer's view on what Discard > Level actually represents. > Yes, indeed. We've been asking about this for months and all the Lindens we've met so far tried there best to help (e.g. Qarl applied some client patches to improve the situation with OpenJPEG) but they were not familiar with the server code and didn't have the time to dig into it which is understandable but so we're still left with some open questions. Carsten From jhurliman at jhurliman.org Sun Sep 28 19:32:09 2008 From: jhurliman at jhurliman.org (John Hurliman) Date: Sun Sep 28 19:32:13 2008 Subject: [sldev] Meaning of RequestImage DiscardLevel field? In-Reply-To: <48DFFB09.80100@gmx.net> References: <48D2D670.3060804@gmail.com> <48D42B6E.1070903@gmx.net> <34cc66250809251140l6856e478w7b881f92b8050d8a@mail.gmail.com> <48DFFB09.80100@gmx.net> Message-ID: I've ran some tests and I think I'm getting a better handle on how the image request system works. However, I encountered a discrepancy between what the LL servers think makes up a DiscardLevel and what OpenJPEG thinks. I've posted the findings here: http://jira.secondlife.com/browse/SVC-3146 John On Sun, Sep 28, 2008 at 10:45 PM, Carsten Juttner wrote: > Teravus Ovares wrote: > >> The client asks for discard level 5... We send it bytes 0-1000. >> The client asks for discard level 3 of the same image.. we know it >> has already received the discard level 5 bytes.. so we send bytes >> 1001-5000. >> >> > > Interesting, that would indicate the discard level in the protocol is also > used as a kind of bookkeeping on the server. Which makes no sense really > since the client is the only one knowing for sure how many bytes it has > already received. > > The only reason to state the discard levels in this way would be to make > sure the client receives the necessary amount of data without having to > parse the packets. > > Which leads to another interesting question: how do they determine the byte > offsets? > Are they guessed (there is a kind of 1/8th rule of thumb built into the > client so it could be the same for the server) or based on the real packet > boundaries in the codestream? > > > But!, it would be nice to get a LL Developer's view on what Discard >> Level actually represents. >> >> > > Yes, indeed. We've been asking about this for months and all the Lindens > we've met so far tried there best to help (e.g. Qarl applied some client > patches to improve the situation with OpenJPEG) but they were not familiar > with the server code and didn't have the time to dig into it which is > understandable but so we're still left with some open questions. > > > Carsten > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080929/e83ff69a/attachment.htm From gigstaggart at gmail.com Sun Sep 28 21:34:49 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Sep 28 21:34:52 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versions don't support OSSL functions In-Reply-To: References: <48DE0E7A.1000504@googlemail.com> <3DD17DC5-BD9D-4D8B-93F0-7171723377D5@gmail.com> <48DE4CA8.3000803@xyzzyxyzzy.net> <55E2C86C-49E8-40D8-A41C-8225968FCE9F@gmail.com> Message-ID: <48E05AE9.4020808@gmail.com> John Hurliman wrote: > It did always fail in the past. However, even when a script compile > fails the source code is still uploaded to the server, so OpenSim would > attempt server-side compilation and ignore any bytecode sent from the > client. This sounds like things are reverting back to how it used to be. In Mono, the script is always uploaded to the server anyway and not compiled client side right? I guess this is a type of "client side lint" check to try to catch syntax errors earlier? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080929/1a055dfe/smime.bin From thordain at thordain.com Mon Sep 29 08:43:05 2008 From: thordain at thordain.com (Thordain Curtis) Date: Mon Sep 29 08:43:09 2008 Subject: [sldev] [SVC] Mono replaces LSL - Better Interoptibility? In-Reply-To: <493033a70809281128ie11c4adpd0a3d452d77b4f0@mail.gmail.com> References: <48DF455A.8060609@signpostmarv.name> <493033a70809281128ie11c4adpd0a3d452d77b4f0@mail.gmail.com> Message-ID: On Sun, Sep 28, 2008 at 2:28 PM, Gordon Wendt wrote: > On Sun, Sep 28, 2008 at 4:50 AM, SignpostMarv Martin > wrote: > >> Last I checked, the plan was to phase out XML-RPC in favour of plain old >> HTTP. >> >> ~ Marv. >> > > And yet it still isn't possible to authenticate to a server which I think > is what many scripers have wanted to be able to do for quite some time to > access secured resources in a secure manner and which has been summarily > ignored by LL. > > -Gordon > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > llHTTPRequest does support HTTP Basic authentication provided you properly format the URL you are requesting. It's a less than documented feature, but it does work if you need it. Observe the difference between: llHTTPRequest("http://thordain.com/authtest", [], ""); and llHTTPRequest("http://authuser:password@thordain.com/authtest", [], ""); The first results in a HTTP 401 while the later works as intended. That being said, even if llHTTPRequest did not support basic auth, that would not necessarily preclude you from designing your own authentication measures that operate within the features availible to you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080929/c86a2048/attachment.htm From whump at lindenlab.com Mon Sep 29 16:50:18 2008 From: whump at lindenlab.com (Bill Humphries) Date: Mon Sep 29 16:50:22 2008 Subject: [sldev] Re: [Gridnauts] heads up: recent secondlife client versionsdon't support OSSL functions In-Reply-To: References: Message-ID: <637F21FE-A48C-41D1-B80D-35A4DE307BA6@lindenlab.com> On Sep 26, 2008, at 5:35 PM, Bill Humphries wrote: > However, the change was made for a reason, and I need some time to > figure out why it was made. Thanks for your patience. > > We are looking at the JIRA Suzy filed, http://jira.secondlife.com/browse/VWR-9332 > . I've asked about the above JIRA, and the recommendation is that you submit a patch for review to the Open Source viewer code. Thanks. -- whump From mumismo at gmail.com Tue Sep 30 05:26:44 2008 From: mumismo at gmail.com (Jordi Polo) Date: Tue Sep 30 05:26:46 2008 Subject: [sldev] physics simulation Message-ID: I have googled about it but I can not find any project using the tools of second life to work with physical simulations. Everything in SL has the physics simulator build in, I mean give an special stress to it. For instance robotics simulation. Where a robot will detect by contact or laser sensor the shape of objects, get a stream of sound from microphones and stream of video (or just photos) from cameras. Traditionally specialized programs are used (Gazebo, Webots, MRS, etc.). The physics simulation of SL is good enough to do something like that? Are improvements on the physics simulation (I guess harvok can be tuned to be more and more precise and CPU intensive) planned for the near future? -- Jordi Polo Carres NLP laboratory - NAIST http://www.bahasara.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080930/10cb0d1b/attachment.htm From gigstaggart at gmail.com Tue Sep 30 05:37:32 2008 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Sep 30 05:37:35 2008 Subject: [sldev] physics simulation In-Reply-To: References: Message-ID: <48E21D8C.9040309@gmail.com> Jordi Polo wrote: > The physics simulation of SL is good enough to do something like that? No. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080930/85036f57/smime.bin From soft at lindenlab.com Tue Sep 30 06:13:24 2008 From: soft at lindenlab.com (Soft) Date: Tue Sep 30 06:13:27 2008 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at: http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From dahliatrimble at gmail.com Tue Sep 30 08:24:24 2008 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Tue Sep 30 08:24:27 2008 Subject: [sldev] physics simulation In-Reply-To: References: Message-ID: The shape of objects can be determined by collision in many cases, also a crude representation of shape is available to scripts with the llGetBoundingBox() API. Sounds are not usually synced well between viewers and are not available to objects, but if the sound is one that is generated by an object then that object could also broadcast some kind of message that another object can "listen" for. Other sounds that are created by collisions or avatar gestures may not be available to objects at all. Video is a viewer effect only and is not necessarily in sync between multiple viewers. The simulator has no information about the video source except for a URL which it passes to the viewer. This is all assuming that a robot is built entirely in world. Something more sophisiticated may be built with a "bot", or an automated avatar client, using tools such as a modified viewer or libopenmv http://www.libsecondlife.org On Tue, Sep 30, 2008 at 5:26 AM, Jordi Polo wrote: > > I have googled about it but I can not find any project using the tools of > second life to work with physical simulations. > Everything in SL has the physics simulator build in, I mean give an special > stress to it. > For instance robotics simulation. Where a robot will detect by contact or > laser sensor the shape of objects, get a stream of sound from microphones > and stream of video (or just photos) from cameras. > Traditionally specialized programs are used (Gazebo, Webots, MRS, etc.). > The physics simulation of SL is good enough to do something like that? > Are improvements on the physics simulation (I guess harvok can be tuned to > be more and more precise and CPU intensive) planned for the near future? > > > > -- > Jordi Polo Carres > NLP laboratory - NAIST > http://www.bahasara.org > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080930/3bfc47e7/attachment.htm From grant at lindenlab.com Tue Sep 30 09:03:26 2008 From: grant at lindenlab.com (Grant Linden) Date: Tue Sep 30 09:03:29 2008 Subject: [sldev] RX Office hours - "What would you remove from the Second Life viewer UI?" Message-ID: <907af5560809300903k2f85e053ka12c405e09f57379@mail.gmail.com> Topic of discussion for this weeks Rx Team Office Hours - General Discussion topic: "What would you remove from the Second Life viewer UI?" Thursday October 2nd from 3:00-4:00 PM SLT http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village For more news about the RX team and to suggest topics for future RX Office Hours please visit our wiki page: https://wiki.secondlife.com/wiki/Resident_Experience The SL-UX Email Discussion List is the ongoing conversation about the Second Life UI and Resident Experience. Residents and Lindens join together to discuss, brain storm and refine the Second Life UI. Join here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux Steven Grant (Grant Linden) User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080930/6cc68fcd/attachment.htm From gareth at litesim.com Tue Sep 30 09:40:49 2008 From: gareth at litesim.com (Gareth Nelson) Date: Tue Sep 30 09:40:53 2008 Subject: [sldev] RX Office hours - "What would you remove from the Second Life viewer UI?" In-Reply-To: <907af5560809300903k2f85e053ka12c405e09f57379@mail.gmail.com> References: <907af5560809300903k2f85e053ka12c405e09f57379@mail.gmail.com> Message-ID: <61dbdd7d0809300940va110671yc5723e5c0937d350@mail.gmail.com> Please bear this in mind: http://www.37signals.com/svn/posts/1118-features-are-a-one-way-street On Tue, Sep 30, 2008 at 5:03 PM, Grant Linden wrote: > Topic of discussion for this weeks Rx Team Office Hours - General Discussion > topic: "What would you remove from the Second Life viewer UI?" > > Thursday October 2nd from 3:00-4:00 PM SLT > http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village > > For more news about the RX team and to suggest topics for future RX Office > Hours please visit our wiki page: > https://wiki.secondlife.com/wiki/Resident_Experience > > The SL-UX Email Discussion List is the ongoing conversation about the Second > Life UI and Resident Experience. Residents and Lindens join together to > discuss, brain storm and refine the Second Life UI. Join here: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sl-ux > > > Steven Grant (Grant Linden) > User Experience Designer > Linden Lab | Second Life > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From leonel.morgado at gmail.com Tue Sep 30 15:23:46 2008 From: leonel.morgado at gmail.com (Leonel Morgado) Date: Tue Sep 30 15:23:58 2008 Subject: [sldev] [ANN] Call for Papers: SLACTIONS 2009 - Life, imagination, and work using metaverse platforms Message-ID: <48e2a6f9.09a8100a.43f2.0c44@mx.google.com> SLACTIONS 2009 Research conference in the Second Life? world - Life, imagination, and work using metaverse platforms September 24-26, 2009 http://www.slactions.org/ *************** CALL FOR PAPERS *************** The metaverse is emerging, through the increasing use of virtual world technologies that act as platforms for end-users to create, develop, and interact, expanding the realm of human cooperation, interaction, and creativity. The conference focus is scientific research on applications and developments of these metaverse platforms: Second Life, OpenSim, Open Croquet, Activeworlds, Open Source Metaverse, Project Wonderland, and others, providing a forum for the research community to present and discuss innovative approaches, techniques, processes, and research results. SLACTIONS 09 is the first international conference held simultaneously in several countries on the topic of metaverses. SLACTIONS 09 aims at covering most areas currently enabled by metaverse platforms, from educational research to content production, from gender studies to media distribution, and from metaverse-based branding, advertising, and fundraising to emerging mash-ups and technology applications. SLACTIONS 09 is unique in its format too, as a one-of-a kind event conducted both in a metaverse platform (Second Life) and on-site in multiple countries in Europe and in North and South America. SLACTIONS will thus contribute to the current redefinition of the way we think about hybrid online and on-site scholarly collaborations. Whereas metaverses are no longer a novel topic, they still pose challenges for the adaption of conventional instructional and business practices, research methodologies, and communication practices. We are looking forward to presenting a program of research results, case studies, panel discussions, and demonstrations that scholars, educators, and businesses can port to their own environments and apply in their research, teaching, and business strategy. We will accept papers from the full spectrum of intellectual disciplines and technological endeavours in which metaverse platforms are currently being used: from Education to Business, Sociology to Social Sciences, Media Production to Technology Development, Architecture and Urban Planning to the Arts. Topics covered may include but are not limited to: * Accessibility in metaverse platforms * Advanced scientific visualization in metaverse platforms * Automatic content generation * Behavioral studies in the metaverse * Combination of metaverse platforms with external systems (e-learning, e-business, etc.) * Communicational paradigms in the metaverse * Content management * Creativity, design, and arts on the metaverse * E-business and e-commerce applications * Educational research, applications, and case studies * Embodiment in metaverses and Gender Studies * GIS/metaverse mash-ups * Integration between metaverse platforms * Nonprofit activities and fundraising * Quantitative and qualitative research methodologies * Social Sciences studies in or through metaverse platforms * Space representation, use, and management in metaverses * Using metaverse platforms for cooperation Format SLACTIONS 09 has the format of a hybrid online and on-site conference. All paper presentations and plenary sessions by guest speakers will be held on-line, and projected locally for participants attending physically. Workshops are conducted locally ? or in mixed format accross several participating chapters ? and chapters may held local topical round tables. Submissions Authors are invited to submit: * A full paper of eight to ten pages for oral presentation * A Flickr image or YouTube video, indexed with the tag ?slactions 09? for poster presentations ?in-world? or presentation in SL using a creative format All submissions are subject to a double blind review process and should be professionally proofread before submission. All manuscripts should be formatted according to the ASIS&T proceedings template. (Disclaimer: SLACTIONS 2009 is not associated with ASIS&T.) No manuscripts will be accepted that do not meet the required format. All accepted papers will be published on-line and in an ISBN-registered CD-ROM/DVD-ROM of proceedings. The Scientific Committee will invite authors of selected full papers to provide revised and expanded versions for publication in an ISBN-registered book. The authors of the best papers will be invited to provide revised and expanded versions for publications in special editions of journals or as single contributions to theme-specific journals. Check out www.slactions.org regularly for more information and developments on the book publisher, book series, and journal venues for best papers. Official language of the conference: The official language for the on-line space and all submissions is English only. However, at the physical site of local chapters you can also use the native language of that location. Important dates * February 28th, 2009 - Deadline for paper submissions * March 31st, 2009 - Submission results provided to authors * June 30th, 2009 - Deadline for early registration * July 31st, 2009 - Deadline for print-ready versions of accepted papers * September 24-26th, 2009 - Conference Local chapters Belgium - Ghent University Brazil/Rio Grande do Sul - Unisinos (Universidade do Vale do Rio dos Sinos) Brazil/S?o Paulo - Pontificia Universidade Cat?lica de S?o Paulo Portugal/North - Universidade de Tr?s-os-Montes e Alto Douro, Universidade do Minho, Universidade de Aveiro, Universidade do Porto USA/Texas - University of Texas-Austin USA/West Coast - University of California-Berkeley Note: If you believe your institution can hold a physical chapter in an as-yet unsupported region, please contact the organization at info@slactions.org. Programme Committee Adriana Bruno, Universidade Federal de Juiz de Fora, Minas Gerais, Brazil Ana Boa-Ventura, University of Texas-Austin, USA Ant?nio Ramires Fernandes, Universidade do Minho, Portugal Augusto Abade, Universidade de Coimbra, Portugal Carlos Santos, Universidade de Aveiro, Portugal Dor Abrahamson, University of California-Berkeley, USA Ederson Locatelli, Unisinos (Universidade do Vale do Rio dos Sinos), Brazil Eliane Schlemmer, Unisinos (Universidade do Vale do Rio dos Sinos), Brazil Jo?o Barroso, Universidade de Tr?s-os-Montes e Alto Douro, Portugal Leonel Morgado, Universidade de Tr?s-os-Montes e Alto Douro, Portugal Lucia Pesce, Pontif?cia Universidade Cat?lica de S?o Paulo, Brazil Lu?s Pedro, Universidade de Aveiro, Portugal Lynn Alves, Universidade do Estado da Bahia, Brazil Martin Leidl, Technische Universit?t Darmstadt, Germany Martin Valcke, Ghent University, Belgium Miltiadis Lytras, Athens University of Economics and Business, Greece Nelson Zagalo, Universidade do Minho, Portugal Niall Winters, London Knowledge Lab, UK Paulo Frias, Universidade do Porto, Portugal Pedro Almeida, Universidade de Aveiro, Portugal Pedro Sequeira, Escola Superior de Desporto de Rio Maior, Portugal Pilar Lacasa, Universidad de Alcal?, Spain Sneha Veeragoudar Harrell, University of California-Berkeley, USA Stefan G?bel, ZGDV, Germany Teresa Bettencourt, Universidade de Aveiro, Portugal Tim Savage, Trinity College Dublin, Ireland Organization Ana Boa-Ventura, University of Texas-Austin, USA Leonel Morgado - Universidade de Tr?s-os-Montes e Alto Douro, Portugal Nelson Zagalo - Universidade do Minho, Portugal Contacts Organization: info@slactions.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080930/e4442309/attachment-0001.htm From kakurady at gmail.com Tue Sep 30 18:58:06 2008 From: kakurady at gmail.com (Geneko Nemeth) Date: Tue Sep 30 18:58:16 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? Message-ID: <48E2D92E.4030101@gmail.com> Hi everyone. First time posting here. In the past year, partly out of being unsatisfied with the existing translation (which is inaccurate and outdated), I translated parts of the Viewer into Chinese (simplified). I tried to submit (see http://jira.secondlife.com/browse/VWR-4263 ) however, it wasn't accepted. Didn't stop me from continuing to translate other parts of the client however. The translation is almost complete, there are several files not translated/updated and parts of it needs to be updated for 1.21. It's kinda weird because Linden Lab's official translator's glossary didn't include many often used words, including "primitive". So sometimes I had to make things up. But more frequently I would keep the original choice of words, even if I don't quite agree with them. A partial list of such words can be seen here: http://wiki.secondlife.com/wiki/User:Geneko_Nemeth/Interface_translation_additional_terms If you're capable of reviewing Chinese and interested please provide your opinions. If you're not, well, I still want to hear how you think of this. Get it here: http://nekotoba.nfshost.com/files/zh.tar.bz2 Kakurady Drakenar (Geneko Nemeth) From TammyNowotny at mac.com Tue Sep 30 19:17:28 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Tue Sep 30 19:17:46 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2D92E.4030101@gmail.com> References: <48E2D92E.4030101@gmail.com> Message-ID: <48E2DDB8.4020909@mac.com> I don't know any Chinese. but I have two thoughts: You are using the same term for agent, avatar and resident. Those are actually three different concepts in SL. The resident is the human being who pushes the mouse and bangs the keyboard. The agent is the entity which does things in world. The avatar is the visible representation of the agent. Also, you might want to use the Chinese word for "atom" or "element" to translate "prim/primitive." The SL term "primitive" is not based on the primary meaning of the word "primitive." Geneko Nemeth wrote: > > It's kinda weird because Linden Lab's official translator's glossary > didn't include many often used words, including "primitive". So > sometimes I had to make things up. But more frequently I would keep the > original choice of words, even if I don't quite agree with them. A > partial list of such words can be seen here: > http://wiki.secondlife.com/wiki/User:Geneko_Nemeth/Interface_translation_additional_terms > > If you're capable of reviewing Chinese and interested please provide > your opinions. If you're not, well, I still want to hear how you think > of this. > > From TammyNowotny at mac.com Tue Sep 30 19:17:20 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Tue Sep 30 19:17:50 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2D92E.4030101@gmail.com> References: <48E2D92E.4030101@gmail.com> Message-ID: <48E2DDB0.5070301@mac.com> I don't know any Chinese. but I have two thoughts: You are using the same term for agent, avatar and resident. Those are actually three different concepts in SL. The resident is the human being who pushes the mouse and bangs the keyboard. The agent is the entity which does things in world. The avatar is the visible representation of the agent. Also, you might want to use the Chinese word for "atom" or "element" to translate "prim/primitive." The SL term "primitive" is not based on the primary meaning of the word "primitive." Geneko Nemeth wrote: > > It's kinda weird because Linden Lab's official translator's glossary > didn't include many often used words, including "primitive". So > sometimes I had to make things up. But more frequently I would keep the > original choice of words, even if I don't quite agree with them. A > partial list of such words can be seen here: > http://wiki.secondlife.com/wiki/User:Geneko_Nemeth/Interface_translation_additional_terms > > If you're capable of reviewing Chinese and interested please provide > your opinions. If you're not, well, I still want to hear how you think > of this. > > From kakurady at gmail.com Tue Sep 30 19:43:09 2008 From: kakurady at gmail.com (Kakurady Drakenar) Date: Tue Sep 30 19:43:17 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2DDB0.5070301@mac.com> References: <48E2D92E.4030101@gmail.com> <48E2DDB0.5070301@mac.com> Message-ID: <48E2E3BD.4000106@gmail.com> Umm, no. "Atom" is a different word than "element"(we're not talking about the chemical type either, mind you). I know that prims in SL is meant to be taken as "geometric primitives", but I'm not sure how to translate that, so I put it as "elemental pieces". As for resident, agent and avatar, I do distinguish between resident and avatar. It's just "agent" is a tad bit hard to translate. Also, it was just a suggestion. (Last thing, automatic translators can't grip the Chinese language very well. Then again...) Kakurady Drakenar (Geneko Nemeth) Tammy Nowotny ??: > I don't know any Chinese. but I have two thoughts: > > You are using the same term for agent, avatar and resident. Those are > actually three different concepts in SL. The resident is the human being > who pushes the mouse and bangs the keyboard. The agent is the entity > which does things in world. The avatar is the visible representation of > the agent. > > Also, you might want to use the Chinese word for "atom" or "element" to > translate "prim/primitive." The SL term "primitive" is not based on the > primary meaning of the word "primitive." > > From tateru.nino at gmail.com Tue Sep 30 20:25:59 2008 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Sep 30 20:26:20 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2E3BD.4000106@gmail.com> References: <48E2D92E.4030101@gmail.com> <48E2DDB0.5070301@mac.com> <48E2E3BD.4000106@gmail.com> Message-ID: <48E2EDC7.6080300@weblogsinc.com> If I had to translate 'agent', I'd probably select 'spirit' - maybe ?? ? (Chinese isn't exactly my forte). An invisible force capable of action. For primitive, perhaps ??. Kakurady Drakenar wrote: > Umm, no. "Atom" is a different word than "element"(we're not talking > about the chemical type either, mind you). I know that prims in SL is > meant to be taken as "geometric primitives", but I'm not sure how to > translate that, so I put it as "elemental pieces". > > As for resident, agent and avatar, I do distinguish between resident and > avatar. It's just "agent" is a tad bit hard to translate. Also, it was > just a suggestion. > > (Last thing, automatic translators can't grip the Chinese language very > well. Then again...) > > Kakurady Drakenar (Geneko Nemeth) > > Tammy Nowotny ??: > >> I don't know any Chinese. but I have two thoughts: >> >> You are using the same term for agent, avatar and resident. Those are >> actually three different concepts in SL. The resident is the human being >> who pushes the mouse and bangs the keyboard. The agent is the entity >> which does things in world. The avatar is the visible representation of >> the agent. >> >> Also, you might want to use the Chinese word for "atom" or "element" to >> translate "prim/primitive." The SL term "primitive" is not based on the >> primary meaning of the word "primitive." >> >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://www.massively.com/ From TammyNowotny at mac.com Tue Sep 30 22:46:21 2008 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Tue Sep 30 22:46:40 2008 Subject: [sldev] [i18n][l10n:zh] Viewer Chinese Translation - feedback wanted? In-Reply-To: <48E2EDC7.6080300@weblogsinc.com> References: <48E2D92E.4030101@gmail.com> <48E2DDB0.5070301@mac.com> <48E2E3BD.4000106@gmail.com> <48E2EDC7.6080300@weblogsinc.com> Message-ID: <48E30EAD.8010302@mac.com> Tateru Nino wrote: > If I had to translate 'agent', I'd probably select 'spirit' - maybe ?? > ? (Chinese isn't exactly my forte). An invisible force capable of action. > For primitive, perhaps ??. > > I am going wayyy out into Cultural-Stereotype land here... but it seems to me that the Chinese language should be rich in words for ghosts, spirits, etc. And even concepts like "prim" or "rezz" might have parallels in Eastern spiritual practices. --Tammy