Re: [opensource-dev] (CTS-315) march choice for 64bit builds
On Sat, 23 Oct 2010 03:08:26 +0200 Boroondas Gupte slli...@boroon.dasgupta.ch wrote: Because SSE2 is now required anyway, -march=pentium4 is now passed for building lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See CTS-315 https://jira.secondlife.com/browse/CTS-315.) What should march be set to for 64bit buids, if anything? pentium4 don't support 64bit, but nocona yes the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] (CTS-315) march choice for 64bit builds
On Sat, Oct 23, 2010 at 3:08 AM, Altair Sythos syt...@gmail.com wrote: On Sat, 23 Oct 2010 03:08:26 +0200 Boroondas Gupte slli...@boroon.dasgupta.ch wrote: Because SSE2 is now required anyway, -march=pentium4 is now passed for building lindenlab/mesh-development. Of course, this doesn't work for 64bit builds. (See CTS-315 https://jira.secondlife.com/browse/CTS-315.) What should march be set to for 64bit buids, if anything? pentium4 don't support 64bit, but nocona yes nocona also enables sse3 which would cut out many k8 cpus. the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: This is the proper fix imho. for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] (CTS-315) march choice for 64bit builds
On Sat, 23 Oct 2010 03:19:24 -0700 leliel leliel.mir...@gmail.com wrote: the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: This is the proper fix imho. for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. let GCC to choose the faster way to assembly machine code... (done under GCC4.5 a lot of test in KV enviroment, but on intel up) is time for a libs update too, especially on multimedia (opeonal, pulse, SSL0.9.7 is buged, etc.etc.), as change compilefarm upgrading GCC (mainly now, mesh need high performance compilated code) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] (CTS-315) march choice for 64bit builds
On Sat, Oct 23, 2010 at 3:44 AM, Altair Sythos syt...@gmail.com wrote: On Sat, 23 Oct 2010 03:19:24 -0700 leliel leliel.mir...@gmail.com wrote: the other (imho better) way to select right march/mtune is use generic and declare *all* parameters, sort of: This is the proper fix imho. for 32bit: gcc -march=generic -mtune=generic -m32 -mmmx -msse -msse2 -mfpmath=both etc.etc. for 64bit: gcc -march=generic -mtune=generic -m64 -mmmx -msse -msse2 -mfpmath=both etc.etc. Should use -mfpmath=sse, gcc isn't very good at doing both x87 and sse fp math at the same time. let GCC to choose the faster way to assembly machine code... (done under GCC4.5 a lot of test in KV enviroment, but on intel up) SSE2 is faster, mfpmath=both tells gcc to use x87 SSE at the same time which is not an easy task given how they work completely different. And it may not even give any speed up, many CPUs share execution hardware between x87 SSE. is time for a libs update too, especially on multimedia (opeonal, pulse, SSL0.9.7 is buged, etc.etc.), as change compilefarm upgrading GCC (mainly now, mesh need high performance compilated code) The first step towards that is to stop using the archaic and down right weird x87 ABI. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] LGPL violation
I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed library statically against a proprietary executable provided you provide the object code or source code of the work that uses the library. In other words, it must be possible to make changes to Qt and *relink*. Translating that idea to linking statically with a shared library, it is clear that one still has to be able to make changes to Qt and relink, or they are non-compliant. This means they must provide all the object code that was used to create (link) libmedia_plugin_gstreamer.so, or they must provide the source code so that people can generate this object code themselves. Imho, the only practical solution is to make the source code availabe, and most likely just all the source code of the whole viewer. On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: Not sure this is worth sending to the list, but could you clarify that .so files are statically linked to the executable that they are loaded into? This is a bit confusing to me. Or are they considered statically linked if you use the default dynamic loading logic, rather than hand-coding GetProcAddr calls or equivalent? Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different on OS other than linux I guess) is a shared library. However, it is constructed by linking statically with a modified version of Qt that was created by LL. Obviously, the users need to know what those mods are and they should be allowed to make changes of their own. For example, someone who already made changes to this version of Qt would not be able to use the mesh viewer until LL releases the full source code, so they are non-compliant if they release a 'beta' version of a viewer without providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt. -- Carlo Wood ca...@alinoe.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] [Linux] Viewer crash with no meaningful error message when cache dir. is missing
Short version: if the Linux viewer can't find the cache directory (even if empty), it will crash immediately, without providing any helpful error message. This happened to me after I moved the cache location to a secondary partition, and ran the viewer while the partition wasn't mounted. As a viewer user, I'd like to get a meaningful error message in such a situation. Opensource Obscure ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Building Alignment Tool by Qarl Fizz
Here's another link to a video. I hope LL can negotiate a price, or a truce, or whatever. http://www.qarl.com/qLab/?p=66 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] [META] User stories and issue tracker readability
As a user of the Second Life issue tracker (jira) who often sorts or searches through others' issues, I'd like people creating or editing issues to place the (sometimes lengthy) user stories into the *Description* field, /not/ the *Summary* field. /The summary should be as short as possible/ while still conveying what the issue is about. The role for whom the issue matters (i.e. As a ..., I ...) and the specifics of the motivation / reason for the issue are important when examining a single issue, but aren't too helpful when looking for duplicates of other issues or when searching for already existing issues of a wish or problem you have. Even worse, because the space for displaying the summary is very limited in some of the greenhopper views, you often only see the As a ... part while the rest gets cut off, so you can't tell at one glance what an issue being discussed is about at all. Think of an issue as a little book. The story you want to tell belongs to the inside (the description). On the cover (summary), you want the story's title (catchy and ideally different from the title of other books), not the first chapter. What do you think? Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] User story: Searchable contacts and inventory notes
As a resident, I would like to be able to search contacts based on contents of contact notes, picks or content of 1st/2nd life tab text. In a related (maybe another story but connected) way, I would like to be able to record notes about inventory items, and search them in the same way. Joel ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] [META] User stories and issue tracker readability
Coincidentally right next to Boroondas's message in my gmail was a message about a change in a years old jira issue I created. Part of the change was to add the words As a user, to the Summary field. https://jira.secondlife.com/browse/VWR-675 They also changed the importance from minor to major. I suspect these two actions are connected. I suspect that people are reading instructions that give them the impression that if they want issues to get proper consideration they need to put As a user at the beginning of the description field. Personally it seems kind of stupid to me to make people type the phrase As a user or similar in the beginning of a text field. If that information is important it should be be in a separate field with a dropdown list of cholces. Then you could sort and filter issues based on Reporter-Type. On Sat, Oct 23, 2010 at 11:00 AM, Boroondas Gupte slli...@boroon.dasgupta.ch wrote: As a user of the Second Life issue tracker (jira) who often sorts or searches through others' issues, I'd like people creating or editing issues to place the (sometimes lengthy) user stories into the *Description*field, *not* the *Summary* field. *The summary should be as short as possible*while still conveying what the issue is about. The role for whom the issue matters (i.e. As a ..., I ...) and the specifics of the motivation / reason for the issue are important when examining a single issue, but aren't too helpful when looking for duplicates of other issues or when searching for already existing issues of a wish or problem you have. Even worse, because the space for displaying the summary is very limited in some of the greenhopper views, you often only see the As a ... part while the rest gets cut off, so you can't tell at one glance what an issue being discussed is about at all. Think of an issue as a little book. The story you want to tell belongs to the inside (the description). On the cover (summary), you want the story's title (catchy and ideally different from the title of other books), not the first chapter. What do you think? Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] LGPL violation
I'm thinking that it may not require full source code if the ABI is published at least -- the only static link that seems involved here is whatever stub (.a?) is necessary to specify the ABI. That would permit someone to link to the library with alternate code (or replace the library with free source if necessary). It looks like they're going down a similar route with the mesh deconstruction code. On Sat, Oct 23, 2010 at 4:27 AM, Carlo Wood ca...@alinoe.com wrote: I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed library statically against a proprietary executable provided you provide the object code or source code of the work that uses the library. In other words, it must be possible to make changes to Qt and *relink*. Translating that idea to linking statically with a shared library, it is clear that one still has to be able to make changes to Qt and relink, or they are non-compliant. This means they must provide all the object code that was used to create (link) libmedia_plugin_gstreamer.so, or they must provide the source code so that people can generate this object code themselves. Imho, the only practical solution is to make the source code availabe, and most likely just all the source code of the whole viewer. On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote: Not sure this is worth sending to the list, but could you clarify that .so files are statically linked to the executable that they are loaded into? This is a bit confusing to me. Or are they considered statically linked if you use the default dynamic loading logic, rather than hand-coding GetProcAddr calls or equivalent? Nah - none of that. libmedia_plugin_gstreamer.so (the extension is different on OS other than linux I guess) is a shared library. However, it is constructed by linking statically with a modified version of Qt that was created by LL. Obviously, the users need to know what those mods are and they should be allowed to make changes of their own. For example, someone who already made changes to this version of Qt would not be able to use the mesh viewer until LL releases the full source code, so they are non-compliant if they release a 'beta' version of a viewer without providing the means to re-link libmedia_plugin_gstreamer.so with a different Qt. -- Carlo Wood ca...@alinoe.com ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Building Alignment Tool by Qarl Fizz
On 2010-10-22, at 14:00, Nalates Urriah wrote: Since the code is already written and working by a former Linden, will it be added to the SL Viewer? Qarl's comment that TPVs are free to use it and that his rates for Linden Lab are reasonable imply... not yet. :) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
