Re: [opensource-dev] List migration next week
On Mon, 13 Apr 2020 10:07:35 -0400, Oz Linden (Scott Lawrence) wrote: > * On Thursday April 16th, the mailman service that drives this list > now will be shut down and all list traffic halted. > .../... > * A new Google Group list with the same name will be established as > soon as we can (hopefully during the following week), and all > current list subscribers will be sent an invitation to that new list. > .../... > If you have questions or concerns, reply to this thread. Here is my question: why shuting down this list before the new list is created and all members are invited to it ?... It sounds like asking for troubles during the migration, and prevents communication for at least a week (if to follow what you are announcing above)... Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 19 Mar 2020 21:24:10 +0100, Henri Beauchamp wrote: > On Thu, 19 Mar 2020 15:29:01 -0400, Oz Linden (Scott Lawrence) wrote: > > > When I log in I get a great deal more than that. > > Strange, to say the least... O.O > > I got debug messages for user auth XML RPC data reply in my viewer, > and I don't see anything else than "additional_listing_cost" and > "num_free_listings" under "account_level_benefits"... OK, it was a bug in the xmlrpc_type_struct processing of my viewer (only the second level and deeper structures were properly taken into account). Sorry for the noise ! Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 19 Mar 2020 21:24:10 +0100, Henri Beauchamp wrote:
> All you need to change is to add in LLLoginInstance::constructAuthParams():
> requested_options.append("agent_appearance_service");
Of course, I meant:
requested_options.append("account_level_benefits");
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 19 Mar 2020 15:29:01 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2020-03-19 11:58 , Henri Beauchamp wrote:
> > However, a couple of things are confusing. Would you please care to explain
> > them:
> >
> > - So far, on login, the only "account_level_benefits" parameters returned
> >by the server are: "additional_listing_cost" and "num_free_listings",
> >which are not even parsed for/used in your code !
> >No parameter dealing with upload costs, creation group cost, attachments
> >limit or picks limit, while your new code relies on them: is it normal
> >(i.e. not yet implemented server-side) or is it a problem with my SL
> >accounts (one premium and several normal/free accounts, all showing the
> >same set of "account_level_benefits" parameters, and just different
> >values) ?
> Where are you logging in?
Anywhere in Agni or Aditi...
> When I log in I get a great deal more than that.
Strange, to say the least... O.O
I got debug messages for user auth XML RPC data reply in my viewer,
and I don't see anything else than "additional_listing_cost" and
"num_free_listings" under "account_level_benefits"...
> > - There is a "ViewerBenefits" capability requested by your new code, but
> >that capability is never used... Is it normal, or is something missing
> >there ?
>
> That's there as a flag to inform the simulator that the viewer
> understands the new benefits mechanism. As far as I know we have not
> used it for anything, but it's there so that if we discover a
> backwards-compatibility problem serious enough we can modify messaging
> or make some other accomodation.
You won't need this "flag" with the "normal" login protocol consisting
for the viewer to request the data associated with that feature on login,
i.e. a viewer implementing or not the "benefits" feature can be flagged
as such as soon as at the login request, while the capabilities (for the
login region) are requested much latter in the login process (and need to
be re-requested at each new region connection, with potential race
condition issues during the long "connect to region" -> "wait for seed" ->
"send caps request" process).
All you need to change is to add in LLLoginInstance::constructAuthParams():
requested_options.append("agent_appearance_service");
Then, when the login server receives the above option request, it flags
the agent/viewer as benefits-aware (no need any more for the unused
capability) and sends the corresponding parameters (and by not sending
them when not requested, you also restore the login compatibility with
old viewers).
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 19 Mar 2020 10:46:27 -0400, Oz Linden (Scott Lawrence) wrote: > The DRTVWR-481 branch has been promoted to the default viewer and pulled > to the master branch. Sadly, there is no corresponding commit to be found: the only commit between the master branch and DRTVWR-481 (which is now gone and cannot be browsed any more) is the opposite one, i.e. the merge of the release viewer branch into DRTVWR-481, prior to the promotion of the latter... So, I downloaded a diffed the master and the v6.3.8 release tags to diff them but, surprise, they only differ by their version number (only one diff in the sources, dealing with the version increment from 6.3.8 to 6.3.9) ! In fact, to get the full batch of changes between the former release tag and the merged DRTVWR-481 branch, I has to diff the sources for the release tags of 6.3.7 and 6.3.8... What a mess ! > TPVs will save their users confusion and reduce support questions by > getting as many users as possible onto viewers with this support by the > time we change the Premium offerings. I don't have a target date for it > I can share, but it's not that far off. I already implemented most of the changes (in my own way, to keep things OpenSim-compatible, i.e. keeping also the old economy-based process), and did not find much added changes in the new diff. However, a couple of things are confusing. Would you please care to explain them: - So far, on login, the only "account_level_benefits" parameters returned by the server are: "additional_listing_cost" and "num_free_listings", which are not even parsed for/used in your code ! No parameter dealing with upload costs, creation group cost, attachments limit or picks limit, while your new code relies on them: is it normal (i.e. not yet implemented server-side) or is it a problem with my SL accounts (one premium and several normal/free accounts, all showing the same set of "account_level_benefits" parameters, and just different values) ? - There is a "ViewerBenefits" capability requested by your new code, but that capability is never used... Is it normal, or is something missing there ? Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] macOS Catalina notarization
On Sat, 29 Feb 2020 10:33:52 -0600, Tonya Souther wrote: > 305 of those libraries are in llplugin, and five are in the SLvoice > for OpenSim. I don't expect that LL has anything to do with the > latter, but the former is the much bigger problem. Is the llplugin > directory still needed? My bet is that those 305 non-signed libraries are in fact VLC's ones... One more reason not to use VLC and to use gstreamer instead: the user may install gstreamer separately on their system (with the proper signing by the gstreamer upstream provider), and you won't need to bundle a shitload of libraries with each binary package of your viewer. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 27 Feb 2020 12:44:31 -0800, Brian McGroarty wrote: > All else aside: In the future, if you notice something on aditi adversely > affects your viewer, please don't be shy about raising it on this list or > in a JIRA. An early heads up may be helpful to other viewer devs, or it > will make it more feasible for the company to alter or postpone a change. Frankly, given the data that was transmitted on login on Aditi in the additional parameters (just a few meaningless strings, including a couple in Russian), I thought it was just a test for some more serious, to-be-announced-and-properly-QAed change that would be implemented later on... There was also, no trace of changes to the login parameters in the viewer(s) code on LL's git repository (no new viewer branch announced either, that would use those new parameters). I won't have imagined that such an essential component as the login server would see its protocol modified on Agni so stealthily and quickly, without even *some* forewarning... O.O Now, I know by experience this actually can happen ! :-/ Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 27 Feb 2020 14:39:10 -0500, Oz Linden (Scott Lawrence) wrote: > That protocol works (and from time to time we employ it) when the change > is one that can be compatible, but that's not the case here. The account > levels are not an optional thing, and there never was any way we could > maintain backward compatibility on the server for viewers that don't get it. You said yourself that: " What will happen with unmodified viewers when the Premium changes go into effect? Most Second Life usage should be fine without the updates, but there may be subtle problems. For example, an unmodified viewer may have the wrong cost for some action; if the viewer expects the cost to be lower than the simulator does, the simulator will reject the request. " I see no mandatory change there, and no breakage in SL server side, so no risk whatsoever for the grid or its services... At worst, the old viewers will not be able to upload assets. Beside, as I already explained: " Which is NOT an issue for most old viewers; e.g. I was using OMV (that just got broken), but never used paying services with it... Another super-useful (actually pretty much *essential*) use case for "deprecated" viewers is to find the origin of a bug: "what was the last viewer version which did not have that bug ?" is the first question I pose to myself whenever a regression bug is found.Was it pre-BOM, pre- Animesh, pre-Materials, pre-whatever-shader-or-render-pipeline-change ? " For the above use cases, there is no issue whatsoever when the viewer does not know about the account level ! > The fact that some incomplete XMLRPC implementations not based on ours LOL Too bad for you: the implementation I used was the one LL wrote for v1 viewers ! So, that's *your* code, not mine ! Beside, the implementation was "complete" (and worked for over 14 years) for the parameters that were in use till you implemented that change without even letting us, TPV developers, test it and give feed back. Instead of apologizing properly and fixing the login server code to *NOT* send the extra info when not requested, you keep trying to find excuses and specious, illogical reasons to justify your failure. So lame... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Thu, 27 Feb 2020 11:10:19 -0500, Oz Linden (Scott Lawrence) wrote:
> The definition of LLSD and our open source implementations of it have
> always included the possibility of arbitrary nesting in arrays and maps
> (and we use it extensively internally without problems). We're not able
> to constrain our designs to maintain compatibility with incomplete
> implementations we may not even know about, much less ones that are
> unmaintained.
1.- To be more precise, the issue is not even about an array in a LLSD,
but about a "structure" (xmlrpc_type_struct) in the XML RPC reply.
Such structures were never used before and therefore the code for
dealing with them was never implemented in many viewers (this got
implemented sometime in LL's v3 code, which did not need to be
backported back then since the said code was unused).
So, it's not about a flawed or deprecated implementation from the
viewer developers' part, but just about a new type of parameter
passed on login, that was not expected by them !
2.- Had you *simply* (this is really trivial, since this is how the
viewers and login server already work !) respected the normal
protocol, not sending any "account_level_benefits" related info
to the viewers not requesting that option on login, there would
not have been *any* problem !
NOTE THAT IT IS NOT TOO LATE: you could *still* modify the login
server code to comply with the list of the requested options and
stop sending the "account_level_benefits" stuff when not requested.
This would *instantly* restore the compatibility with the old
viewers, and all you would have to change in the new viewer code
is to add:
requested_options.append("account_level_benefits");
in LLLoginInstance::constructAuthParams()
> That having been said, we'll try to provide more advance warning for
> future changes when possible. Note that the further in advance the
> notice comes, the less specific and actionable it can be.
The simple fact of announcing the change (and explaining it) in Aditi
after it was done and asking for testing and feedback would have
avoided the entire mess...
Draw your own conclusions about LL's communication and QA processes,
but I'd personally say, based on observation of the result, that they
are flawed.
And by the way:
On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote:
> The changes are in the 'DRTVWR-481
> ' branch in
> the viewer git repository.
> .../...
> When can we release these changes?
>
> We strongly encourage you to integrate these changes as soon as
> possible. You are free to begin incorporating the changes and releasing
> them any time (but please watch for updates to them).
Too bad... The only parameters currently sent in Agni by the login
server are "additional_listing_cost" and "num_free_listings", and nothing
else (in particular, no upload cost, no max group membership). So, should
someone backport the changes as currently implemented in the repository
you point at (i.e with the LLGlobalEconomy removed), they would end up
with a non-functionnal viewer in SL !
'nuff said !
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer changes for Premium changes
On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote:
> *As we mentioned at the last Third Party Viewer meeting,
Oh yes, those meetings a non-English speaking developer cannot follow
because they are held in voice chat... How nice and practical a way
of communication !
> the upcoming changes to Premium levels will require some viewer
> updates to maintain full compatibility.*
This is not just "full compatibility", because sadly, the way you (LL)
chose to implement the "benefits" rendered many old viewers incapable
of login into SL. More on that below.
> Why are there changes?
>
> The viewer currently has some messages and costs hard coded
They are _*NOT*_ hard-coded. The cost is modified after login on
receiving the EconomyData message (the process_economy_data() callback
is implemented in indra/newview/llviewermessage.cpp).
By the way, that's how OpenSIM grid can (and always could) deal with
different costs than in SL.
Granted, only the fixed upload cost (currently L$10 in SL) is transmitted
by the server and used by the viewers, but extending the message with
more costs (and/or changing that cost server side, based on the logged
in avatar account level) would have kept old viewers compatible with the
login process.
> that will need to be sensitive to the account type of the user. Rather
> than just telling the viewer the users’ account level (which we will
> also do) and then putting code into the viewer to adjust based on that
> type, we have built a more general solution. A new key ('benefits') in
> the LLSD map returned by login identifies a map whose keys are "benefit
> tags" and whose values are what that benefit level is for the logged-in
> user.
Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers
(i.e. all viewers not based on LL's v3 viewer code for the XML RPC part)
do not know what to do with such an array (they can only deal with simple
key/value pairs, not with key/arrays); this was the case of my viewer
(but I thankfully and by pure "luck" noticed the issue a few weeks before
LL did stealthily modify the login server on the main grid, because the
beta grid already had the changes which caused me to fail to login in it
at that time, and I could diagnose and fix the issue).
> For example, one of the benefit tags is "texture_upload_cost"; its value
> is the number of L$ required for this user to upload a texture. The
> viewer displays that cost in the upload dialog so that dialog must be
> modified to use the value returned in the tag rather than the L$10 that
> is currently hard coded.
This particular usage is useless and redundant, since EconomyData/
process_economy_data() already can change that value in real time (and
in fact, it could even occur on a per-sim basis if needed, and not just
at login !).
> Where are the changes?
>
> The changes are in the 'DRTVWR-481
> ' branch in
> the viewer git repository. A viewer built from that branch will be
> available as a Release Candidate soon.
It would have been nice to give a sufficient forewarning to avoid breaking
the login process on the main grid for many viewers (or viewer versions):
Radegast, my viewer (all versions before v1.26.24.2 are unable to login
in SL any more), OMV, etc, etc, etc.
> When can we release these changes?
>
> We strongly encourage you to integrate these changes as soon as
> possible. You are free to begin incorporating the changes and releasing
> them any time (but please watch for updates to them).
We don't have any choice, because of a poor design of the said changes.
Beside the redundant aspect (with the EconomyData message), there was
no backward compatibility guard.
Even if you want to get rid of EconomyData (even if I don't see why),
it would have been dead easy to implement the following protocol:
- on login request by the viewer, the server looks at the
requested_options map (see LLLoginInstance::constructAuthParams()).
- if the said map contains the "benefits" keyword, then the server
sends the benefits array in its reply, else it omits it.
This way, old viewers (that don't know what to do with that array) are
still able to connect, and new viewers needing that array can request
it.
> What will happen with unmodified viewers when the Premium changes go
> into effect?
>
> Most Second Life usage should be fine without the updates, but there may
> be subtle problems. For example, an unmodified viewer may have the wrong
> cost for some action; if the viewer expects the cost to be lower than
> the simulator does, the simulator will reject the request.
Which is NOT an issue for most old viewers; e.g. I was using OMV (that
just got broken), but never used paying services with it...
Another super-useful (actually pretty much *essential*) use case for
"deprecated" viewers is to find the origin of a bug: "what was the
last viewer version which did not have that bug ?" is the first
Re: [opensource-dev] Error related to libndof when trying to compile SL on Ubuntu (attempt 2)
On Fri, 7 Feb 2020 00:51:27 -0500, Andras Farkas wrote: > I was watching a friend play Second Life and thought it looked cool > (I'm really into MUCKs, so VR is a cool topic in general) so I decided > I'd try to compile it on FreeBSD, my desktop OS. FreeBSD is not a build target for the viewer: beyond the need to rework the build system (and corresponding #defines in the sources), you'd lack all the pre-built libraries that the viewer needs. > I decided to try compiling it on Ubuntu first, to examine the build > process. However, I encountered an error related to libndof, as seen > in the attached errout.txt Do not use Linden Lab's sources to try and build a Linux viewer: you would invariably fail. [rant] You can thank LL for not providing support for Linux; while they benefit for free from all the work done by GNU/Linux developers and while SL won't even exist without their work (especially on the server side of things, but even the viewer is using a shitload of Open Source components that have been primarily developed under and for GNU/Linux). That's how LL is repaying the Open Source community when they could just "devote" one developer to simply reuse the work TPV developers did for Linux, and provide a Linux supported viewer. Hell ! I've been maintaining (and vastly improving) my own viewer (and not just for Linux) for the past 13 years, alone, and only on part of my sparse free time: don't tell me a programmer at LL cannot maintain a Linux viewer: all what it would take them (once their viewer is brought on par with TPVs' Linux support) is just a couple of hours of work *per week* ! [/rant] Instead, try TPV sources. My viewer (Cool VL Viewer) builds with just a single command under any Linux distro (just type ./buildlinux.sh in a terminal pointing in the linden/indra/ directory). It would also be a good candidate for a FreeBSD port: it got a stand- alone build system (so adding FreeBSD to the cmake files would not be an impossible task), and the sources/scripts for building the pre-built libraries are also provided (http://sldev.free.fr/libraries/sources/ ). Be warned however, that porting the viewer to *BSD would require C/C++ programming skills (i.e. beyond what is needed to simply compile the viewer or its libraries), and that I won't be of help for this task (no *BSD system here, and no time whatsoever to devote to such a port). On Fri, 07 Feb 2020 17:57:29 +1100, Alex wrote: > Many things would also be missing and would need implementing, like CEF > and dullahan Not sure there is a recent enough port of CEF (*), indeed, but once you got the CEF binaries, building Dullahan won't be much of an issue, using my sources/script as a base. (*) With a quick search on the web, I only found this: https://github.com/prash-wghats/Brackets-CEF-for-FreeBSD/tree/master/CEF but it's way too old (CEF 51, and currently using CEF 74). > and voice support. Voice support is largely hosed under Linux anyway (the v2.1 voice client, which is the last Linux version Vivox provided, still works for public voice chat, but you cannot do voice with another resident not using themselves that same old client). However, for a vast majority of SLers (especially non native-English- speaking residents, but also all genuine role-players), voice is not even a useful feature of SL (never using it myself), so... > Also, FreeBSD's OSS (open sound system) is not implemented in the viewer Wrong ! The viewer got support for OpenAL, which itself supports the OSS backend. FMOD sound would however be ruled out (not really an issue either since OpenAL can do sound, including streaming). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] viewer-release vs The Penguins
On Thu, 6 Feb 2020 12:05:17 +0100, Nicky D. wrote: > I know. I already looked at it for Firestorm. But LL won't let you > contribute this as we know due to their CA standards. I see... I was apparently mistaken by the 'vs' term in the subject of your message, and by the fact your viewer-linux sources was hosted on a private repository and not on LL's. I thought it was just a "generic Linux viewer" forked from LL's viewer-release, and as such, open to any Open Source developer's contributions (or at the very least, suggestions). > I'd really like to get rid of the GTK dependency. Even if only for > Firestorm. Like I suggested (if I'm still permitted to do that), you could also go the Qt route, which I believe would be much cleaner, easier, future-proof (GTK4 is already in the pipeline and will incur even harder breakages), and better for the end user (with Qt, as a user, you can choose the look and feel and the theme, including GTK2's if you fancy it !). > As long as we're speaking about a viewer LL might want to integrate > (debatable if it ever happens), taking contributions of others is out > of the question. Taking contribution from others without CA is > completely unthinkable. Like is unthinkable for me to sign a CA that requests personal information that go way beyond the purpose of such an agreement. LL shall respect the Law of the country of the contributor, with regard to their CA, and they simply don't. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] viewer-release vs The Penguins
On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > it has been a while since LL released their last Linux capable viewer. To > get things started > again I brought 6.3.6 up to Linux support: > https://bitbucket.org/NickyD/viewer-linux > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > scripts) > > As I know the chances to see a penguin fly are bigger than get a release > from LL, I also created a flatpak that users can install and run > (instructions below). I fail to see the advantage of a flatpak, when the current distribution method (i.e. bundling libraries that are likely to lack on the user's system, or that have been patched) do work nicely... Flatpaks are huge and bloated with stuff that the viewer won't really need (but are just non-essential dependencies to some libraries it uses). The alternative to both flatpaks and dynamic libraries bundling in the viewer distribution is to statically link all libraries that are likely to be missing on the user's system. That's what software like Firefox or Blender do for their pre-compiled Linux binaries distributions. > Differences in the Linux version: > - Uses SDL2 rather than SDL (so the "OS" version can be used). That's an interesting and useful change, that I'll probably pick-up for my own viewer: SDL2 is the path to the future anyway (with Wayland support, even though the latter is likely to stay inappropriate for running the viewer in the foreseeable future, since NVIDIA proprietary drivers don't support it and Open Source NVIDIA drivers are way too slow or right out incomplete). However, I would recommend to keep linking statically SDL2 to the viewer binary, since SDL2 is far from a mandatory prerequisite in many Linux distros (i.e. it is not always installed by default). > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > version. I solved the GTK dependency a looong while ago... By removing it entirely ! The viewer depends on GTK under Linux only for the text clipboard (and it is not even properly implemented with it), and for the file selector (which lacks proper threading, or causes threading bugs/slow downs when threading is attempted). My solution has been to re-code the clipboard stuff directly with Xlib primitives (with proper primary and secondary paste buffer support) and to code an XUI file selector, that also works for Windows and macOS by the way, with a code that is beautifully simple and largely OS-independent (only a few #if LL_WINDOWS here and there to deal with Windows file system peculiarities, such as with hidden files and drive volume names), since it relies on llcommon classes to deal with OS-dependent stuff. An alternative, if you want to keep an OS-dependent file selector, would be to migrate to Qt's: easier and cleaner to implement in C++... > - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. > Once FMOD Studio gets into the viewer I add it to the Linux release. I got support for FMOD Studio in my viewer for a long while too. Quite easy to implement based on FMOD Ex implementation. The only loss is support for the (rarely used) OSS backend in FMOD (but OpenAL can use it, and I got both OpenAL and FMOD Studio supported in my Linux viewer). > - No KDU. I obviously don't have access to LLs version of KDU and won't > use the one I have for Firestorm. OpenJPEG does a good job anyway (pretty much as fast as KDU too, when compiled with SSE2/3 support). Just make sure to use a SL-compatible version (I use a heavily patched v1.4.0.635 personal fork, with security fixes and SSE optimizations backported from v2). Here again, OpenJPEG is best statically linked to the viewer (I even integrated its sources to the viewer sources, since they are so specific/heavily modified). > - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets > updated by the OS (Flatpak in this case) rather than shipping some ancient > VLC version. I totally agree with you. Beside, like I already explained back in 2016 in this list, GStreamer would also be a better choice for Windows and macOS users: it only needs to be installed once and for all (i.e. no need to bundle a huge amount of libraries with the viewer, like is the case of VLC) and solves all software patent issues (users can choose what CODECs they install on their system, depending on where they live and/or how "sensitive" they are towards the patent issues). I use Gstreamer for all OSes in my viewer: never got a single complaint from any user for doing so... > - dullahan/CEF is added. So it got the usual web browser as Windows/OSX got. > - It's obviously unsupported. I provided and kept up to date the sources for a Linux-compatible Dullahan since November 2015 on my site... That could count as "support", I think... :-D Another thing you might want to look at is getting rid of the deprecated, unsupported and utterly buggy dbus-glib dependency. I solved this a long time ago by coding DBus support based
Re: [opensource-dev] Firestorm viewer on RaspberryPi
On Fri, 26 Apr 2019 14:24:32 +0100, Jack Lang wrote: > I'm trying to port Firestorm to Raspberry Pi Are you serious ? O.O Since mesh has been implemented, the viewer code is tightly bound to x86 processors, because it makes a large use of SSE2 math. You'd have to translate all that code into an ARM equivalent (Neon); while doable, it's not for the faint-hearted. Even if you could get the code to compile (which would involve to also recompile all the pre-built libraries, such as Dullahan, Collada and a few others you likely don't have in the Pi's distro), there are also the *big* problems with the CPU and GPU speeds; the resulting viewer would likely render at under 5fps, at best (and in a skybox with no avatar around)... And finally, there is the *wall*: 1Gb of RAM is notably too little to run a viewer (even a v1 viewer such as mine, even compiled for 32 bits). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SL server issues in the past 4 months
On Mon, 8 Apr 2019 10:49:42 -0400, Oz Linden (Scott Lawrence) wrote: > On 2019-04-08 09:27 , Henri Beauchamp wrote: > > In the hope my observations will help you guys to get things back on > > track (because it's getting really badly needed). > > Thank you Henri. > > We are very much aware of these problems and trying hard to correct > them, but I believe you may have added some useful insights; I've > forwarded your message to the two teams I have attacking them. Thank you ! In the mean time, I managed to diagnose the rebake issue and fixed it: what I found out could, perhaps, also be a hint about what happens for failed TPs. The problem was a race condition (as it is often the case in the server/viewer communication): my workaround for derezzing attachments triggered a rebake in the arrival sim, but I did not check whether the capabilities for that sim were received or not; this did not cause any issue before last week (i.e. rebaking with old (cached, in my viewer) capabilities URIs did not matter), but it does now (whether it is the result of a changed timing, algorithm or policy on the server side is of course unknown to me). In my new code, I simply flag the rebake as needed and now actually perform it only once the capabilities for the new agent region are received, and everything works like a charm (well, not fully, since that workaround should not even be needed in the first place, and the bogus kill-objects message on agent attachments is still wrongly sent by the departure region). Now, why might it be related at all with failed TPs ?... Well, if the capabilities are received too late, and seeing how viewers implementing region-Windlight are way more prone to timeouts than mine, it could indeed be that the viewers are attempting to use a capability that is not yet available, causing a timeout... Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] SL server issues in the past 4 months
Greetings, I'm writing this email because I'm getting tired of having to pile up workarounds in my viewer code for all the SL server issues that have appeared in a succession and every few weeks since mid December, and think it is time for you folks, at LL, to do some serious review of the latest changes you brought server-side. 1.- Bogus attachment kill messages on region change. This issue appeared mid-December 2018 and results in derezzed (but still active) attachments on region change (sim border crossing or TP alike). I instrumented my viewer code so to be able to trace the problem. Here is how to witness it occurring in real time: Get the Cool VL Viewer, disable the workaround for lost attachments (un-check Advanced -> Network -> Ignore bogus kill-attachment messages), enable the "Attachments" debug tag (from Advanced -> Consoles -> Debug tags) and the debug console, then TP and/or cross region boundaries. Just watch the debug messages that will allow you to track every event dealing with your attachments thanks to the special debug code I added to understand and fix this issue. You will see that, often (but not always), the departure sim sends a "kill object" messages for your attachments (which causes them to de-rez in your viewer) while you are already in the arrival region; in this case, the arrival region usually sends a re-parenting message for your attachments (they get parented to your avatar again and thus re-rez). Sadly, the re-parenting message is sometimes (often) not always received or incomplete, or even received before the kill message from the departure region (race condition), causing some attachments not to re-rez in your viewer. Interestingly, the arrival sim always got the correct, full list of your attachments since you will notice that, even if not rezzed, they are still active (their scripts still work): this is also why, when TPing or crossing a boundary to another sim, your attachments often reappear (the region still transmitted them right to the next sim). To make things even more complicated, the bake server (which keeps a copy of the COF) seems to receive as well the kill and re-parent messages from the sims, and is therefore reflecting the same bad state for your attachments in its copy of the COF; this is why, in my workaround for that bug (which simply ignores the bogus kill object messages sent from the departure sim), I also trigger a COF full resync (wearables + attachments) and a rebake. What I do not understand in the first place, is why the Hell the departing sim sends kill_objects messages at all to the departing avatar for its attachments ! The attachments follow the avatar and therefore do not change parent. Even their position, being relative to the parent avatar, does not change. Same thing for the bake server that apparently receives the same message while it should not (the avatar outfit did not change at all, and even if a scripted object could get detached on arrival as a result of a scripted changed() LSL event, that event would still occur in the arrival sim and sent from it to both the viewer and the bake server: the departure sim shall never have anything to so with objects attached to the avatar !). 2.- Bogus rebakes with bad body textures. For about one week now, the above workaround (which worked fine for almost 4 months) gets partly defeated because the rebake it triggers gets the bake server to return bogus textures for the body parts (sometimes a layer, such as a tattoo, is missing, other times it's like if the avatar was not wearing any skin texture). Of course, the user can still rebake manually to get it fixed (well, at least in my viewer, since I'm not even sure you still can rebake in LL's official viewer), but this is extremely annoying and pretty much inexplicable by me (nothing wrong, seen viewer side, just bad baked textures arriving). So, I was in the process of coding yet another workaround (double-rebake after the bogus kill-attachment message is ignored) when I decided to write this email, because this is just getting *ridiculous* ! 3.- Failed event polls. For about 3 weeks, and almost always since last week, I get failed/retried event polls, which never happened before. Here is a log of one such failed poll: DEBUG: LLCoreHttpUtil::HttpCoroHandler::onCompleted: Error Http_499 - Cannot access url: https://sim10685.agni.lindenlab.com:12043/cap/287c7dfd-63d1-a74c-6670-17f4f2d1d5c3 - Reason: Malformed response contents INFO: LLSDXMLParser::parse: XML_STATUS_ERROR parsing: INFO: LLSDXMLParser::parse: XML_STATUS_ERROR parsing: DEBUG: LLCoreHttpUtil::HttpCoroHandler::onCompleted: Returned body: 502 Proxy Error Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request http://localhost:13011/agent/b43c4b76-3816-49ce-933d-e1a4eef3226e/event-get;>POSThttp://localhost:13011/agent/b43c4b76-3816-49ce-933d-e1a4eef3226e/event-get. Reason: Error reading
Re: [opensource-dev] Windows ReleaseOS build unable to load textures
You might want to use my modified version of OpenJPEG v1.4.0.635 (that is included in the Cool VL Viewer source and built in-tree with the viewer) instead of any later versions that got utterly broken for SL usage... My version includes the needed security fixes from v1.5+ as well as some crash bug fixes. It is also (somewhat) SSE-optimized. It works beautifully and this, for years, in the Cool VL Viewer. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP asset fetching will soon be mandatory
On Mon, 29 Oct 2018 17:59:13 -0400, Oz Linden (Scott Lawrence) wrote: > On 2018-10-19 09:52 , Henri Beauchamp wrote: > > > My viewer has long been updated to make use of the newest HTTP fetching > > capabilities, but it also implements an automatic fallback to UDP fetches > > when HTTP ones fail (i.e. a texture failing to be served via HTTP is > > automatically re-requested using UDP). > > Better to requeue the request to HTTP after a suitable backoff (unless > of course you get a error that indicates that a retry would not work). The fallback happens only for unrecoverable errors, of course (for other errors the HTTP retry policy is used)... > > Also, will AIS be made mandatory or will the non-AIS HTTP inventory > > operations still be available ? The reason for this question is that > > AIS is still suffering failures from time to time, and the only solution > > in that case is to disable it (or restart the sim)... > > The effort to disable the UDP inventory operations is separate; Well, the effort should concentrate on making AIS3 operations reliable, because so far, they never have been. I'm still getting 400 errors from time to time, causing failures to update the inventory when they happen (which in turn may cause rezzing failures, when it affects the COF). As long as AIS3 is not 100% reliable, I would strongly advise *NOT* to disable UDP inventory operations... > but if there are UDP inventory operations you're using now that can be > done through AIS, then you should be making those changes. This has been implemented years ago in my viewer, so I'm not worried about the code changes (already done) but only about the reliability of inventory ops for the end user... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] HTTP asset fetching will soon be mandatory
On Mon, 15 Oct 2018 15:27:12 -0400, Oz Linden (Scott Lawrence) wrote: > In the interests of continuing to improve performance and user > experience, we will be removing the old non-HTTP fetching methods from > our simulators in early 2019. This means that any viewers that are still > fetching the affected asset types via UDP will no longer work correctly > after that time. > > The affected asset types are: > * AT_LANDMARK > * AT_CLOTHING > * AT_BODYPART > * AT_GESTURE > * AT_ANIMATION > * AT_SOUND I don't see AT_TEXTURE listed: does it mean that we will still be able to fetch textures via UDP sim messages ? My viewer has long been updated to make use of the newest HTTP fetching capabilities, but it also implements an automatic fallback to UDP fetches when HTTP ones fail (i.e. a texture failing to be served via HTTP is automatically re-requested using UDP). Also, will AIS be made mandatory or will the non-AIS HTTP inventory operations still be available ? The reason for this question is that AIS is still suffering failures from time to time, and the only solution in that case is to disable it (or restart the sim)... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] specifying wich python binary to use?
On Sun, 23 Sep 2018 10:56:52 +0200, Lance Corrimal wrote: > the trick with the link did not work either, cmake is evil enough to > actually search for python binaries WITH the attached version number. cmake is for nothing in this behaviour (else, I'd encounter it as well for my viewer and distro, the latter also having both python2 and python3 installed). It's likely a bug in LL's build system... Note that my viewer is using a largely modified build system (derived from Snowglobe v1's), that can build on pretty much any Linux distro (but for 6+ years old ones, since they won't fulfil minimum cmake and/or gcc versions requirements), and which does not rely on any external resource (such as "autobuild", "llbase" and all that non-sense)... Glad you found the solution however. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] specifying wich python binary to use?
On Sat, 22 Sep 2018 15:43:14 +0200, Lance Corrimal wrote: > I have python 2 and python 3 installed on my system, is there a way to > specify > which python version autobuild should use? by default it tries python3, which > fails. Depending on your distribution, you may specify (or not) which Python version is to be used when invoking 'python', with: alternatives --config python If it does not work, you may trick the build system by creating a "python" link to the python2 binary and then changing the PATH so that your link is found first. E.g. from a terminal: mkdir -p ~/bin ln -s /usr/bin/python2 ~/bin/python export PATH="$HOME/bin:$PATH" then from the same terminal, launch the build. When running any command, a script ran from that terminal will first look into the bin/ subdirectory of your home directory before looking in the rest of the $PATH directories, and "python" (linked to python2) will be found there... You may also make this a permanent feature for your login, by chanching ~/.bashrc and putting in it the same: export PATH="$HOME/bin:$PATH" For a system-wide change, create the link in /usr/local/bin and change the system-wide default PATH (usually to be found in /etc/bashrc) to list /usr/local/bin as the first directory. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] compiling viewer-release on linux
On Fri, 21 Sep 2018 20:33:00 -0700, John Nagle wrote: > Here's how I currently compile successfully on Linux. > This builds the development version 5.1.9, not the release version. > > Install all prerequisites per > http://wiki.phoenixviewer.com/fs_compiling_firestorm_64bit_ubuntu wget http://sldev.free.fr/sources/CoolVLViewer-src-1262219.tar.bz2 tar xJf CoolVLViewer-src-* cd linden/indra ./buildlinux.sh > I've been running this version for about a month now without trouble. I've been running my viewer under Linux for 11+ years without trouble ! :-D No, seriously, the question in the original message was not about help for building third party viewers under Linux, but for issues with LL's own viewers... LL would be well inspired to have a look at TPVs' build systems for Linux... Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Miscellaneous bad code in llviewerobject.cpp
On Fri, 21 Sep 2018 16:51:14 -0700, John Nagle wrote: > I've been looking for the "half-unsit" region crossing bug, > adding debug code to llviewerobject. Something is going wrong > in reparenting, but I haven’t been able to isolate it yet. > > Looking in there, I've found some code that's wrong, but > probably not causing trouble. > > - Two possible buffer overflows. Reported to LL, being treated as > a security issue. It would be nice to share your findings with us too: LL is slow to fix bugs in their code, and it will be weeks before we see the corresponding commit appear in their repository... > - Unchecked downcasts on polymorphic types. Those are risky. Many such static downcasts are there because of the LLXform -> LLPrimitive -> LLViewerObject inheritance. Since no code would create LLPrimitive or LLXForm instances outside LLVierwerObject inherited ones, the said static casts are safe, and much faster (zero overhead) than dynamic casts (+ NULL check)... But I agree that it is a bad practice and many such casts could be avoided by moving some members to the LLXform class, such as using an mIsAvatar boolean in LLXform, set by LLPrimitive inside setPCode(), then moving isAvatar() from LLPrimitive to LLXform: this way, you can test for avatar parent objects using mParent (which is a LLXform) without having to donwcast... I just implemented this for my viewer. > There's at least one place where an unexpected message from the sim > will cause an invalid downcast. That's been reported to LL. Again, it would be nice to share with us... > (Does anybody still read this list?) * raises his hand * Regards, Henri ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] macOS 10.14 deprecation of OpenGL, what does this mean for SL?
On Mon, 4 Jun 2018 22:41:48 -0700, Dahlia Trimble wrote: > But seriously, perhaps LL should consider writing a new viewer with a > modern, API-agnostic rendering layer. OpenGL is stagnant on just about > every platform now. OpenGL is not stagnant (v4.6 dates only from July 2017): it is simply mature. However, next generation OpenGL is not v5.0 but rather Vulkan (the latter allowing to take a much larger benefit from multi-core CPUs, at the cost of a lower level API and thus more work and complexity for the 3D application programmers). As for SL viewers, I'd love to see a Vulkan renderer developed, but I doubt it will happen any time soon... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] macOS 10.14 deprecation of OpenGL, what does this mean for SL?
On Mon, 4 Jun 2018 15:25:55 -0700, Kadah Coba wrote: > So just heard about this, not sure if this was known about before this. > https://developer.apple.com/macos/whats-new/ > > "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, > but these legacy technologies are deprecated in macOS 10.14. Games and > graphics-intensive apps that use OpenGL should now adopt Metal." > > There's doing the same on iOS too, not that it effects us. > > Knowing Apple's way, could likely assume 10.15 or 10.16 may not support > OpenGL at all, or at worse, a later update of 10.14.x. Apple always has been an horrible company when it comes to computing standards: they produce closed platforms with closed software and apparently did not yet understand that the computing world trend is the exact opposite, with more and more cross-platform software using open standards so that they can be compiled and used under any OS with minimal efforts and adaptation. If they want to keep shooting in their foot, so be it. Developers (and Open Source ones will be the first) will simply stop developing Apple- compatible software and Apple will end up as a niche platform (which they pretty much are already, when we speak about *serious* computing: any example of servers or super-computers running under any Apple OS ?). For me, it always has been a total mystery that people could even *consider* buying their expensive, poorly performing, deprecation- scheduled stuff. As for OpenGL, Apple's drivers always sucked at it (big time), so it's perhaps that they simply finally admit they are incompetent programmers, unable to produce reliable and good performing OpenGL drivers. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] building a viewer: fails with some undefined variables
On Sat, 31 Mar 2018 15:20:50 +0200, Lance Corrimal wrote: > After closer inspection it seems that LL_LINUX, LL_DARWIN or LL_WINDOWS > need to be defined to get the right things done right in the include > files... shouldn't autobuild make sure of this? I don't use autobuild for my viewer (its build system is "stand alone" and derived from Snowglobe's). All you have to do to build a Linux binary of the Cool VL Viewer is to point a terminal in linden/indra/ and type "./buildlinux.sh"... I wish building LL's viewer was just as simple. But these defines used to be added from indra/cmake/00-Common.cmake where you could find lines such as: if (LINUX) .../... add_definitions(-DLL_LINUX=1 -D_REENTRANT) .../... endif (LINUX) and the equivalent for Windows and Darwin. You could simply re-add the 'add_definitions(-DLL_=1)' lines in 00-Common.cmake... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] building a viewer: fails with some undefined variables
On Sat, 31 Mar 2018 13:36:28 +0200, Lance Corrimal wrote: > Hi guys, > > I'm trying to build a viewer on linux, and the build fails due to several > undefined variables, which, given their names, should actually be defined > somewhere in the source, or in the autobuild_variables_file: > > error: #error "LL_ALIGN_PREFIX and LL_ALIGN_POSTFIX undefined" > error: 'LL_DEFAULT_HEAP_ALIGN' was not declared in this scope > > happens right after the actual build starts. > > Where do I get those variables? $ grep -r LL_ALIGN_POSTFIX linden/indra/* | grep '#define' linden/indra/llcommon/llmemory.h:#define LL_ALIGN_POSTFIX(x) __attribute__((aligned(x))) linden/indra/llcommon/llmemory.h:#define LL_ALIGN_POSTFIX(x) linden/indra/llcommon/llmemory.h:#define LL_ALIGN_16(var) LL_ALIGN_PREFIX(16) var LL_ALIGN_POSTFIX(16) You probably failed to #include "llmemory.h" in the sources where this error happens. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] CDN
On Fri, 23 Mar 2018 14:51:30 -0500, Nicky Perian wrote: > What is the procedure for determining which CDN node is use for viewer > instance. CDN server IPs are served by your DNS, the latter being updated with the closest CDN server. I.e. if you live in one country and use a DNS hosted in another, you get the IP of the CDN server of that other country instead of yours... The assumption is that people are likely to use a DNS close to their home (usually, they use their ISP's DNS). E.g. for me (in France) with my ISP's DNS: # nslookup maps-cdn.agni.lindenlab.com maps-cdn.agni.lindenlab.com canonical name = secondlife.edgesuite.net. secondlife.edgesuite.netcanonical name = a336.d.akamai.net. Name: a336.d.akamai.net Address: 88.221.83.50 .../... # whois 88.221.83.50 inetnum:88.221.83.0 - 88.221.83.255 netname:AKAMAI-PA descr: Akamai Technologies country:EU (actually, 88.221.83.0/8 is in France) .../... Now, via dnscrypt (with a DNS in Canada): # nslookup maps-cdn.agni.lindenlab.com maps-cdn.agni.lindenlab.com canonical name = secondlife.edgesuite.net. secondlife.edgesuite.netcanonical name = a336.d.akamai.net. Name: a336.d.akamai.net Address: 23.15.4.17 .../... # whois 23.15.4.17 NetRange: 23.0.0.0 - 23.15.255.255 CIDR: 23.0.0.0/12 NetName:AKAMAI .../... Country:US > Then, how do you determine which assets are present on that CDN and not > present in the viewer? Not sure what you mean, here... The viewer requests an asset to the CDN server and if the asset is already cached in the latter, it is immediately transfered to the viewer, else the CDN server asks to the upstream server for that asset, caches it and transfers it to the viewer. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Fri, 23 Mar 2018 01:48:08 +1000, Alex wrote:
> It does indeed sound like the viewer is subsequently spawning another
> SLPlugin instead of dullahan_host, you are right. I have no idea why the
> viewer would be doing that. From what I am aware, the viewer _should_
> start one instance of SLPlugin and dullahan_host when its at the login
> screen.
>
> Do you have a rough idea (assuming the standard LL viewer behavior)
> where these processes get launched from on startup (which part of the
> viewer code)?
In fact, the viewer (and SLPlugin) code itself got no knowlegde of
dullahan_host: the latter is launched (and gets passed arguments) by
CEF, from a setting given in dullahan_impl.cpp, in dullahan_impl::init()
My guess is that your plugin lacks a #elif defined(__linux__) and the
corresponding CefString(_subprocess_path) there.
Here is what I put in mine:
bool dullahan_impl::init(dullahan::dullahan_settings& user_settings)
{
DLNOUT("dullahan_impl::init()");
#ifdef WIN32
CefMainArgs args(GetModuleHandle(nullptr));
#else
CefMainArgs args(0, nullptr);
#endif
CefSettings settings;
// point to host application
#ifdef WIN32
CefString(_subprocess_path) = "dullahan_host.exe";
#elif __APPLE__
NSString* appBundlePath = [[NSBundle mainBundle] bundlePath];
CefString(_subprocess_path) =
[[NSString stringWithFormat:
@"%@/Contents/Frameworks/DullahanHelper.app/Contents/MacOS/DullahanHelper",
appBundlePath] UTF8String];
#elif defined(__linux__)
CefString(_subprocess_path) = "dullahan_host";
#endif
// Do not bother with the stupid sandbox which keeps failing under Windows
// and which must be set UID root under Linux...
settings.no_sandbox = true;
.../...
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Thu, 22 Mar 2018 16:31:29 +0100, Henri Beauchamp wrote: > In my viewer, SLPlugin is never passed any other argument than the port, > so maybe these arguments you see passed are an "extension" to Firestorm's > plugin system... In fact, looking at the processes for a viewer on at login sceen step, I get: 4283 ?S 0:00 /bin/bash /usr/local/CoolVLViewer-1.26.21/cool_vl_viewer 4309 ?SLl0:02 ./bin/cool_vl_viewer-bin 4326 ?Sl 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/SLPlugin 41321 4330 ?S 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=zygote --no-sandbox --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14 (Cool VL Viewer; default skin)) Chrome/65.0.3325.146 [64bit] - 4356 ?Sl 0:00 /usr/local/CoolVLViewer-1.26.21/bin/llplugin/dullahan_host --type=renderer --no-sandbox --disable-gpu-compositing --service-pipe-token=3FECC7FC7B452E7F87FF8F85FB58EB32 --lang=en-US --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 4357 ?Sl 0:00 dullahan_host --type=gpu-process --no-sandbox --log-file=/root/.secondlife/ --product-version=(Dullahan:1.1.1080 [64bit] - SecondLife/1.26.21.14 (Cool VL Viewer; default skin)) Chrome/65.0.3325.146 [64bit] --lang=en-US --gpu-preferences=KA So, the argument you are seeing are actually dullahan_host ones ! Could it be that your viewer launches SLPlugin instead of dullahan_host ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Thu, 22 Mar 2018 23:39:51 +1000, Alex wrote:
> 2018-03-22T10:08:12Z llplugin/slplugin/slplugin.cpp(194) : error
> 2018-03-22T10:08:12Z ERROR: llplugin/slplugin/slplugin.cpp(194) : main:
> port number must be numeric
> .../...
> 4589 execve("/home/alex/ivyviewer/bin/SLPlugin",
> ["/home/alex/ivyviewer/bin/SLPlugin", "38655"], [/ 66 vars /]
>
> 4592 execve("/home/alex/ivyviewer/bin/SLPlugin",
> ["/home/alex/ivyviewer/bin/SLPlugin", "--type=zygote", "--lang=en-US",
> "--log-file=/home/alex/ivyviewer/bin/debug.log",
> "--product-version=(Dullahan:1.1.820 [64bit] - SecondLife/5.1.3.54978
> (Firestorm-private-x64build; firestorm skin)) Chrome/59.0."...], [/ 69
> vars /]
>
> I am seeing SLPlugin called once correctly, with the port number it
> expects, then it is being called a second time with data that it is not
> expecting, thus the error condition is triggered in slplugin.cpp
>
> I know this is a bit of a shot in the dark but can you think of any
> possibilities why this could happen?
Hard to tell without having the sources to look at, but to me, it would
appear like an arguments quoting or missing argument issue in the command
line passed to SLPlugin...
In my viewer, SLPlugin is never passed any other argument than the port,
so maybe these arguments you see passed are an "extension" to Firestorm's
plugin system...
You'll have to follow the track in the code, starting from LLViewerMedia,
then LLPluginClassMedia, LLPluginProcessParent, LLProcessLauncher, etc...
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Wed, 21 Mar 2018 16:59:58 +1000, Alex wrote: > Just a quick question about the above. In the list for > target_link_libraries, the first two make sense to me, but what is 'cef' > referring to? is it libcef.so? Yes, under Linux, ld uses the provided library and searches for , lib.so, lib.a, etc... But your problem was related to a bad call in your plugin (did you read my message dated Wed, 21 Mar 2018 00:43:41 +0100 ?). In media_plugin_cef.cpp, simply replace the calls to: set*Callback(boost:bind(::on*Callback..., _1, ...)) with: set*Callback(std:bind(::on*Callback, std::placeholders::_1, ...)) Or (to keep the boost interface and C++98 compatibility) use my plugin and Dullahan versions, but you can't mix LL's C++11 Dullahan with the old boost-wrapped calls in the CEF plugin. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Wed, 21 Mar 2018 09:38:07 +1000, Alex wrote: > libmedia_plugin_cef.so:00114cd0 T > dullahan::setOnStatusMessageCallback(boost::function (std::string)>) > libmedia_plugin_cef.so: U > dullahan::setOnStatusMessageCallback(std::function) The problem is that the dullahan::setOnStatusMessageCallback() definition is using ***boost::function*** and the plugin is calling dullahan::setOnStatusMessageCallback(***std::function***) So, the plugin is searching for another method than the one linked together with libdullhana.a... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Wed, 21 Mar 2018 08:58:55 +1000, Alex wrote: > On 2018-03-21 07:57, monty wrote: > > > 'nm' that thing and see what is definition and what is reference. > > I pasted the result here: > > https://pastebin.com/BZyKEJf2 > > command used: nm --print-file-name -u libmedia_plugin_cef.so With the -C option you would get more readable, demangled symbols... > Lots of undefined symbols... So this means there is a reference but no > definition? It lists: U _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE So it indeed shows that the libdullahan.a library did not get properly linked to your plugin... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Wed, 21 Mar 2018 07:32:08 +1000, Alex wrote: > On 2018-03-21 04:10, Henri Beauchamp wrote: > > But only twice... I get it listed thrice in my plugin... > > strings > > /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so | > > grep _ZN8dullahan26setOnStatusMessageCallback > > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE > > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE > > _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE > > > > (there's "boost" because I "re-boostified" Dullhan's interface for > > C++98 compatibility). > > Ah. But in the case of boost and dullahan, it was making use of header > only parts of boost right? Yes, only templates from the three boost/function.hpp, boost/bind.hpp and boost/move/unique_ptr.hpp headers are used. > Relinking libcef twice didnt help sadly.. I gave up for the night and > went to sleep hehe. Do you have any ideas what else might be causing it? Beside a linking problem (either in libdullahan.a itself or in the plugin), I'm short of ideas... > On 3/20/2018 17:32, Alex wrote: > > > Interesting that that symbol is defined 3 times in your library. > > 'nm' that thing and see what is definition and what is reference. AFAIK, nm only lists exported symbols (i.e. the entries for the definitions), not their invocations from another linked module (the references). nm -C /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so | grep setOnStatusMessageCallback 000ed710 T dullahan_callback_manager::setOnStatusMessageCallback(std::function) 000e4090 T dullahan::setOnStatusMessageCallback(boost::function) These correspond to the two definitions of the homonymous methods in the Dullahan's library classes 'dullahan' and 'dullahan_callback_manager', but nm does not list the call to dullahan::setOnStatusMessageCallback() from media_plugin_cef.cpp, which should correspond to the third string in media_plugin_cef.so. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 22:30:14 +1000, Alex wrote: > On 2018-03-20 22:00, Alex wrote: > > 2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of > > /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with > > error 20019 , additional info string: > > /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined > > symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE > > > > Any ideas what might be behind this one? > > Something I noticed: > > alex@desktop:~/ivyviewer/bin/llplugin$ strings libmedia_plugin_cef.so | > grep ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE > _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE > _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE > > The symbol is there... But only twice... I get it listed thrice in my plugin... strings /usr/local/CoolVLViewer-1.26.21/bin/llplugin/media_plugin_cef.so | grep _ZN8dullahan26setOnStatusMessageCallback _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE _ZN8dullahan26setOnStatusMessageCallbackEN5boost8functionIFvSsEEE (there's "boost" because I "re-boostified" Dullhan's interface for C++98 compatibility). So, it looks indeed like a linking issue even though: On Tue, 20 Mar 2018 23:20:59 +1000, Alex wrote: > gcc/g++ version 4.9.4 > GNU ld (GNU Binutils for Ubuntu) 2.29.1 Using the same versions here, for personal builds, with no issue whatsoever. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 14:15:09 +0100, Henri Beauchamp wrote: > Looks fine to me... Putting the blame on a buggy ld, you could try this > trick (specifying libcef.so twice for linking) in CEFPlugin.cmake: Or... This could be an issue in how you linked libdullahan.a and/or dullahan_host... In the Dullahan Cmake file, check for the proper ordering in target link libraries: target_link_libraries(dullahan_host cef_dll_wrapper cef) Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 22:48:05 +1000, Alex wrote:
> I couldn't spot a problem in either of those files, but my eyes might
> have missed something.
>
> Does anything stand out at you:
>
> https://pastebin.com/c7wRQik8 (indra/cmake/CEFPlugin.cmake)
> https://pastebin.com/ZhytizN8 (indra/media_plugins/cef/CMakeLists.txt)
Looks fine to me... Putting the blame on a buggy ld, you could try this
trick (specifying libcef.so twice for linking) in CEFPlugin.cmake:
.../...
elseif (LINUX)
set(CEF_PLUGIN_LIBRARIES
${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
-Wl,-whole-archive
${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
-Wl,-no-whole-archive
${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
)
endif (WINDOWS)
What is your Linux build system ?
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 22:30:14 +1000, Alex wrote: > The symbol is there... I'm not seeing any 'not found' errors when I > check that plugin with ldd. Depending on your ld version (old ones are very sensitive to the library link order), this could be an issue with not linking the libraries in the proper order... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 22:00:36 +1000, Alex wrote:
> Well, I am a little closer :)
>
> I have a different error now.
>
> 2018-03-20T11:53:39Z WARNING: LLPluginInstance::load: apr_dso_load of
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so failed with
> error 20019 , additional info string:
> /home/alex/ivyviewer/bin/llplugin/libmedia_plugin_cef.so: undefined
> symbol: _ZN8dullahan26setOnStatusMessageCallbackESt8functionIFvSsEE
>
> Any ideas what might be behind this one?
Apparently a failure to properly link libdullahan.a to your plugin
(the library should be statically linked and so apr_dso_load() should
not search for this method symbol at all)...
Still something wrong in indra/cmake/CEFPlugin.cmake, or perhaps a
failure to specify the $CEF_PLUGIN_LIBRARIES in
indra/media_plugins/cef/CMakeLists.txt
Watch out for (similar) lines in it:
set(media_plugin_cef_LINK_LIBRARIES
${LLPLUGIN_LIBRARIES}
${MEDIA_PLUGIN_BASE_LIBRARIES}
${CEF_PLUGIN_LIBRARIES}
${LLCOMMON_LIBRARIES}
${PLUGIN_API_LIBRARIES}
)
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 19:58:49 +1000, Alex wrote:
> This is what I get:
> alex@desktop:~/ivyviewer$ LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd
> ./bin/llplugin/libmedia_plugin_cef.so
> linux-vdso.so.1 => (0x7ffcedd68000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x7f07a805e000)
> libaprutil-1.so.0 => ./lib/libaprutil-1.so.0
> (0x7f07a7e15000)
> libapr-1.so.0 => ./lib/libapr-1.so.0 (0x7f07a7be5000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f07a785f000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> (0x7f07a7509000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f07a72f2000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f07a70d3000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x7f07a6cf3000)
> /lib64/ld-linux-x86-64.so.2 (0x7f07a867)
> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
> (0x7f07a6aee000)
> libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
> (0x7f07a68b6000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x7f07a66b2000)
>
> alex@desktop:~/ivyviewer$ find . -name 'libcef.so'
> ./lib/libcef.so
>
> I would have expected to see a 'not found' in the ldd output if it had
> not been copied or it was sitting somewhere outside of LD_LIBRARY_PATH.
> Is it likely has gotten screwed up during the link of
> libmedia_plugin_cef.so?
Yes, obviously, libcef.so did not get linked with your plugin...
Check your indra/cmake/CEFPlugin.cmake: the library names changed there,
from libllceflib.a to libdullahan.a. Note also the bit of vodoo magic
needed under Linux to avoid seeing ld "optimizing out" the functions that
are needed in libcef_dll_wrapper.a and libdullahan.a. It should look like
this (note the -Wl,-[no-]whole-archive options):
if (LINUX)
set(CEF_PLUGIN_LIBRARIES
-Wl,-whole-archive
${ARCH_PREBUILT_DIRS_RELEASE}/libcef_dll_wrapper.a
${ARCH_PREBUILT_DIRS_RELEASE}/libdullahan.a
-Wl,-no-whole-archive
${ARCH_PREBUILT_DIRS_RELEASE}/libcef.so
)
endif ()
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 10:24:24 +0100, Henri Beauchamp wrote: > On Tue, 20 Mar 2018 10:22:43 +0100, Henri Beauchamp wrote: > > > LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path > > bin/llplugin/libmedia_plugin_cef.so > > I meant: > LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd > ./bin/llplugin/libmedia_plugin_cef.so And without the typos in "library", it actually is: LD_LIBRARY_PATH="./lib:$LD_LIBRARY_PATH" ldd ./bin/llplugin/libmedia_plugin_cef.so * drinks a cup of strong expresso, slaps his face twice and re-reads thrice * Should be OK, this time... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 10:22:43 +0100, Henri Beauchamp wrote: > LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path > bin/llplugin/libmedia_plugin_cef.so I meant: LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./bin/llplugin/libmedia_plugin_cef.so Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux x64 - libmedia_plugin_cef.so error
On Tue, 20 Mar 2018 18:45:54 +1000, Alex wrote: > I am working to try and get a Linux version of the FS viewer running and > I have been successful for the most part after fixing a bunch of build > issues.. however I seem to have an issue with CEF failing in the new > viewer, this can be seen in the logs: > > 2018-03-20T07:44:13Z WARNING: LLPluginInstance::load: apr_dso_load of > /home/alex/fsivy/bin/llplugin/libmedia_plugin_cef.so failed with error > 20019 , additional info string: > /home/alex/fsivy/bin/llplugin/libmedia_plugin_cef.so: undefined symbol: > AtomicOps_Internalx86CPUFeatures > > Some Googling reveals that AtomicOps_Internalx86CPUFeatures is part of > CEF? Has something gone wrong with linking somewhere? > > What might have gone wrong for this to happen? I am out of ideas as to > what it might be. Any thoughts appreciated. When typed from a terminal pointing in your viewer directory, what does LD_LIRABRY_PATH="./lib:$LD_LIRABRY_PATH" ldd ./path bin/llplugin/libmedia_plugin_cef.so tells you ? If it can't find libcef.so, then it would explain it... Make sure your viewer_manifest.py script does properly copy all the CEF libraries, binaries and resources in the right places. Also, you will find a working Dullahan Linux plugin on the Cool VL Viewer site (in http://sldev.free.fr/libraries/ ), as well as the corresponding sources (in http://sldev.free.fr/libraries/sources/ ). Note however that this is a modified version with extended parameters for CEF (to learn how to use them, have a look at indra/media_plugins/libvlc/media_plugin_libvlc.cpp in the sources for the Cool VL Viewer v1.26.21.x). This plugin can also be used to compile the viewer with a non C++11 compliant compiler (e.g. with gcc v4.6, even though you will still need to link the viewer to a version of libstdc++.so v6.0.19 or newer (shipped with gcc v4.8 or newer), since this is what libcef.so expects), unlike LL's version. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Libraries -- Linux
Greetings, Sorry for this late reply, but the last two weeks were quite busy for me. On Thu, 22 Feb 2018 13:34:45 -0600, Nicky Perian wrote: > I am in process of rebuilding all linux libraries. So am I, since LL's new set of pre-built Linux libraries is totally broken and unusable... > I had in 2015 broken apart gtk-atk-pango-glib into individual autobuild 3p > type repositories. I'd recommend getting rid of the gtk-atk-pango dependencies... I mean, GTK2 is pretty much deprecated nowadays, with GTK3 out for a while and GTK4 arriving. For the Cool VL Viewer, I rewrote the copy/paste code to use Xlib instead of GTK+, and my code implements both the primary (mouse-select to copy and middle mouse button to paste) and secondary (CTRL C/X/V) buffers. I also got rid of the file selector (for all OSes) by implementing an XUI-based one. Advantages: - It is natively non-blocking (the GTK threading is a nightmare and does not play well with the viewer's own threading). - Its code is MUCH simpler than LL's convoluted, OS-specific code and is largely OS-agnostic (but for a few #if LL_WINDOWS here and there to cope with the silly layout of the Windows file system). - It provides an uniform experience to the user, whatever the OS they use, matching what they experience already with the rest of the viewer UI. As for glib, do make sure to use the same version as the one linked to CEF (libcef.so being built on Ubuntu 14.04 LTS, you should use the corresponding glib version, namely v2.40.2). One thing that you could get rid from as well is the old, deprecated and broken (*) dbus-glib dependency: I rewrote dbus support using gdbus instead, and it only takes 6 kB of sources (all inside llappviewerlinux.cpp) to do what LL's dbus-glib implementation does with 18 kB (with 5 more files)... As usual, feel free to LGPLize and reuse my code. (*) "Recent" (post v0.92) dbus-glib versions got a server-side bug causing a timeout while the message was successfully passed... > I have an issue with fontconfig. I cannot isolate freetype from the system > version and have during configure You need to export FREETYPE_LIBS and list in that variable the full path names of both your custom libfreetype.a and libz.a. You can find the "sources" (often just a build script and patch(es), the script taking care of downloading the upstream sources and patch them when necessary) for the Linux libraries I rebuilt so far here: http://sldev.free.fr/libraries/sources/ Note that I adopted Rosa 2014.1 for my (32 and 64 bits) build systems, with Ubuntu 14.04 LTS also used, but only for Dullhan (so that the latter gets the exact same dependencies as libcef.so: glib is one such dependency that cannot be "forced" on CEF at Dullahan build time: CEF will keep using the system glib version, no matter what, and since Rosa 2014.1 is using a newer version, I'd better not build Dullahan on it if I want my viewer to run on Ubuntu 14 and simlar systems...) So to keep the lowest requirement on the libstdc++ library needed to run the viewer, I also compiled and packaged gcc v4.8.5 for Rosa 2014.1 (Ubuntu uses v4.8.4 and Rosa uses v4.9.4 as their system compiler) and use it to build the libraries and the viewer; if you are interested, I could post the Rosa 2014.1 RPM packages I built for gcc v4.8.5. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On Fri, 2 Feb 2018 13:33:22 -0600, Nicky Perian wrote: > Having read the comments on viewer-release repo and your comment concerning > ABI mismatch I want to submit the following: > > I have put together in a VM Debian / stretch. My past linux builds have > been on Ubuntu 14.04 and 16.04 using gcc-4.8 and 4.9. To ensure compatibility with 4/5 years old systems (which seems to me like quite a reasonnable premise), the problem are: - Most of these systems are still using gcc v4.x (and, most important, its associated libstdc++ library using the old ABI) and all the LL-supplied libraries should therefore be compiled with either gcc v4.x (x = 7 to 9, given, alas, 4.6 is not fully C++11 compliant and cannot compile stuff like CEF), *or* have the _GLIBCXX_USE_CXX11_ABI=0 define set so that the old C++ ABI is used (the same define should then also be set in the viewer sources via the 00-Common.cmake file for gcc v5+ and clang). - The glibc version of the build system must not be too high (v2.19 looks like the newest version found on such systems). In fact, the older the glibc version, the better and the broadest the compatibility (old pre-built libraries were compatible with glibc v2.13+). - The glib v2.0 version should also be the oldest possible, since glib is used by CEF and other pre-built libraries. Using a build system with too recent a glib library would also result in missing symbols or mismatches. In fact, the gcc version matters less (thanks to the_GLIBCXX_USE_CXX11_ABI=0 trick you can use with gcc v5+ versions to retain compatibility) than the versions of *glibc* and *glib2*. Since CEF is now the most demanding library about the build system dependencies (with glibc v2.19 and glib v2.46 on the CEF build system, namely Ubuntu 14.04 LTS), I suggest we stick with those for now. FYI, the current stable release of the Cool VL Viewer builds with gcc v4.6 to v7.3 (probably with gcc v8.0 as well) and clang v3.8 to v6.0RC1 (and probably with v3.6 and 3.7 too) and the builds I release (built on a modified Rosa 2012 distro) run on pretty much any post-2012 distro. I am planning to adopt Rosa 2014.1 for my next build system (I already built Dullahan, both 32 and 64 bits on it) for the experimental Cool VL Viewer release and the next stable one. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On Fri, 26 Jan 2018 01:34:09 +0100, Henri Beauchamp wrote: > However, it might be a problem with Dullahan, since CEF is now compiled with > Ubuntu 16.04 LTS, Scratch that ! On the CEF build Wiki, they cite 14.04, but the link points to a page that itself points to 16.04... So, if to believe the Wiki text, Ubuntu 14.04 is used to build the latest CEF... Ubuntu 14.04 uses gcc v4.8 and glibc 2.19, just like Debian Jessie (either of those two could then be the Linux build system of choice). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On Tue, 23 Jan 2018 09:09:22 -0500, Oz Linden (Scott Lawrence) wrote: > On 2018-01-23 07:05 , Nicky Perian wrote: > > Which version of Debian does LL plan to use? Stretch is at stable. > > I had been planning on Jessie, but this took longer than I hoped, so > yeah we'll go for Stretch. Debian Stretch uses gcc v6.3 and glibc v2.24, which are quite new and will cause pre-built libraries to be unusable on distros with gcc v5 or older... Debian Jessie uses gcc v4.8 (which does not have the new C++ ABI, but this can be fixed when compiling with v5+ gcc against libraries built with the old ABI by defining _GLIBCXX_USE_CXX11_ABI=0) and glibc v2.19, which should make it compatible with all reasonably recent distros (post-2014)... However, it might be a problem with Dullahan, since CEF is now compiled with Ubuntu 16.04 LTS, which uses gcc v5.4 (new ABI, so when compiled with gcc 4.8, you won't be able to link Dullahan against the pre-built CEF) and glibc v2.23... An alternative would be to use Ubuntu 16.04 LTS as a build system. All distros with gcc v5 and newer would then be compatible with the builds, and no issue to fear with CEF. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Animated mesh (Axon viewer branch)
Greetings, I was wondering if there was any sim, on Aditi, where I could give a test for the Axon viewer branch code (animated mesh). I searched for a sim with it enabled, but failed to find one so far... Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] How to deal with FMODEX?
On Sat, 25 Feb 2017 09:56:30 -0600, Nicky Perian wrote: > Which platform are you using? > > You may want to use a non-commercial license of FmodEx. Then, send an email > to FMOD support explaining your use of non-commercial provisions of their > license and that you need access of FmodEx archives. > > It may take time for them to respond as there isn't any money involved. I asked them access on Sat, 13 Aug 2016, and they enabled access on my account and replied with an email on Mon, 15 Aug 2016. They would hardly have been able to reply faster. :-D Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries
On Thu, 2 Feb 2017 08:14:21 +0100, Geir Nøklebye wrote: > The viewer still crash in the occlusion code, but not as often as > without these changes. Meaning you actually didn't fix anything... Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On Mon, 30 Jan 2017 18:41:07 +0100, Nicky D. wrote: > - Standalone is afaik broken since a long time, for example there is > missing FindXXX.cmake files for various packages. Many such files are actually part of the cmake package or added by the devel packages of some libraries. See: /usr/share/cmake/Modules/Find* > - As far as I know are there no system packages for (at least) glod, > colladadom, breakpad and cef. > > - Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example > I cannot find anything older than 2 > for Debian Wheezy). Possibly this can be worked around with non > standard deb repositories in apt.conf. > > - Compiling the deb eg on Squeeze and trying to install it on > something Wheezy based could lead to > interesting results, due to the dependent packages from the Squeeze > system being recorded in the deb. > (Or compiling on Wheezy and installing on Jessie and so on). I resolved the "STANDALONE" (now "SYSTEMLIBS") issue for my viewer by making it so that libraries that are not likely to be present in distros, or not properly patched for SL viewers, or simply incompatible, are still downloaded as the pre-built viewer libraries (i.e. the resulting viewer binary is linked against a mix of commonly available system libraries and exotic/patched pre-built libraries). It more or less works, i.e. it works on my system (PCLinuxOS) but one of my users encountered an issue with this method recently (probably because of his distro's curl library, which I will probably mark as "use-pre-built-curl-only" in future releases). Your best bet is however to keep building the viewer using the pre-built libraries and packaging it together with them (/usr/games/YourViewerName is a good candidate for the packaged build destination). > - VLC: Henri pointed out a few times, that the VLC api is not exactly > stable between releases. Gstreamer would be better... I would have pointed you to the archived messages on this list in which I went to great extents to explain everything in details, but the archive is currently down... > - Boost will be interesting You cannot currently using system boost libraries: they lack LL's custom coroutine stuff... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] List archive down ?
Greetings, It's been a couple of weeks that I noticed it: the archive site for this list seems to be down: https://lists.secondlife.com/pipermail/opensource-dev/ reports "Unable to connect"... Did the address change (it's still the one listed on the Wiki) or is this a problem with a badly configured server ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Linux
On Sun, 29 Jan 2017 20:54:42 -0500, Monty Brandenberg wrote: > On 1/29/2017 8:39 PM, Nicky Perian wrote: > > > Will LL use a build system that can be updated as opposed to the current > > out of date system? Hopefully, the build system will be a standard off > > the shelf that everyone can install and without any mix and match specials. > > The "one, true Linux?" > > /me reaches for box of popcorn... /me steals popcorn in Monty's box, and speaks with a mouthful. /me chewing, "Ya know..." /me gulps, "Excuse me..." All it takes is writing a shell script allowing to build your viewer. Then packagers just have to invoke that script via whatever package build system you use (rpm, deb, ebuild, you name it). /me steals another handful of popcorn and points at his viewer sources Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 64 bit viewers build instructions
On Fri, 13 Jan 2017 21:53:51 -0600, Nicky Perian wrote: > Texture quality when openjpeg-1.5 is used ranges from poor to piss poor 64 > bit is worse. > Screenshots attached, openjpeg-1.5.1 and openjpeg-1.4.0. These are on the > same viewer with only openjpeg.dll changed. There are "fixes" that went into OpenJPEG v1.5 and newer, that break textures in SL (I posted in this list, long ago, about one such issue). However v1.5 and v2.0 bring security holes fixes and bug fixes. That's why I integrated the OpenJPEG v1.4 sources to my viewer (in indra/libopenjpeg/) and patched these sources with all the fixes I could find in v1.5 and v2.0 repositories and that are not ruining texture decoding in SL, as well as with a few more security checks (potential crash bug fixes) by me. Feel free to grab the Cool VL Viewer's "libopenjpeg" and integrate it in your own viewer. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Fri, 16 Dec 2016 11:14:59 -0800, Richard Nelson wrote: > FWIW, those particular units types were introduced as part of the LLTrace > metrics update and found several cases where the incorrect units were > being recorded, resulting in skewed/invalid metrics. The point is not > that it is hard to multiply by a constant to do unit conversion...it is > that programmers sometimes forget to, so it is hard to know how much you > can trust metrics that have not been thoroughly vetted in the code. The guy with the anvil and the hammmer had a good reason too. :-D I would have solved this issue differently, e.g. by ensuring all variables used in the viewer code classes to track down memory usage use the same "unit" (more like a multiple, here), such as bytes in S64 variables (or kilobytes in S32), then also making sure all those variables names bear the unit (multiple) name in their own name (e.g.: mTextureMemoryBytes). With a comment or two in appropriate locations in the stats sending methods, stating what units are to be used, this would have covered both current and future usages of memory tracking for coders. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Fri, 16 Dec 2016 10:07:45 -0500, Monty Brandenberg wrote: > On 12/16/2016 4:16 AM, Henri Beauchamp wrote: > > > I'd say that the demonstration of how templates can actually > > harm the maintainability of the code is done... > > Hahaha, that is a permanent on-going debate. I said *can harm*, not *always harm*... There are very appropriate and efficient uses of templates, but the one in question is not (it's more like using a hammer and an anvil to squash a bug). :-) Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Fri, 16 Dec 2016 09:44:51 +0100, Henri Beauchamp wrote: > my viewer is therefore unafffected by that bug... In fact, I had a doubt and checked: it was affected, but the fix took me exactly 3 minutes to perform (4 static variables in LLImageGL and LLViewerTexture that were S32 integers and that I made into S64 ones): compared to what it will take you to edit the templatized names in all files, I'd say that the demonstration of how templates can actually harm the maintainability of the code is done... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about BUG-41029 and 64 bit usage
On Thu, 15 Dec 2016 11:13:35 -0800, Callum Prentice (Callum) wrote: > https://jira.secondlife.com/browse/BUG-41029 > > .../... > > There is a lot usage of 32 bit types (U32Bytes, U32Megabytes etc.) defined > indirectly here: > > https://bitbucket.org/lindenlab/viewer64/src/9270caf3d4324f9c1c33aa158f80e0fe84036a48/indra/llcommon/llunittype.h?at=default=file-view-default#llunittype.h-824 > > that are used to count memory sizes/usage/difference etc. I think we can > convert them to their U64 equivalents for all viewers. > > Nat points out, rewriting this code using size_t as a return type would > make more sense but that seems like it would involve more invasive code > changes including changes in fundamental LL headers. > > What does the collective wisdom say? My *personal* wisdom says that this U32Bytes/U32Megabytes templatized thingy is just the expression of the lazyness of its coder (frankly, is it *that* difficult to use a constant multiplier to convert from bytes to megabytes ?) and just adds more complexity to the generated code without any benefit whatsoever. As a result, I did not backport this non-sense to the Cool VL Viewer and kept everything in normal variables (U32 for megabytes, U64 for bytes, etc), using constants to convert from one unit to the other when needed; my viewer is therefore unafffected by that bug... My advice would therefore be to revert the corresponding commit. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 64 bit viewers build instructions
On Thu, 8 Dec 2016 18:07:42 -0600, Nicky Perian wrote: > Possible Correction, Parts of this were in declined Pull Request #4 > This is windows only Darwin and Linux will need a similar code. Not needed for Darwin (the FMOD Ex Darwin library is a fat binary with both 32 and 64 bits code in it). For Linux, just add: elseif (LINUX) if (ADDRESS_SIZE EQUAL 64) set(FMODEX_LIBRARY debug fmodexL64 optimized fmodex64) else (ADDRESS_SIZE EQUAL 64) set(FMODEX_LIBRARY debug fmodexL optimized fmodex) endif (ADDRESS_SIZE EQUAL 64) Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] 64 bit viewers build instructions
On Sat, 3 Dec 2016 19:12:31 -0600, Nicky Perian wrote: > *only issue is that some script is trying to copy fmodex.dll Speaking of FMOD Ex, you might want to update it. The current version is v4.44.64 and got crash fixes over the one you are using... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] SL Wiki locked down ?
On Sat, 20 Aug 2016 17:08:12 -0700, Brian McGroarty wrote: > Please create a support ticket or ping Oz after one of the TPV meetings if > you would like to request edit access on the wiki. There is a ridiculously > persistent party who uses numerous wikis to promote fake Microsoft support > phone numbers. Given the fraud or malware potential, we couldn't let that > keep returning. Thank you. I created a ticket in the "web login issue" category, pointing at this thread in the web archive of this list. I totally understand and support your concerns however, may I suggest that your webmaster creates an SQL ASCII export of the (clean) Wiki database and 'grep' it for all contributor names, then whitelist them ? This should not require more than one (at worst two) man.hours of work. TPV developers are not the only contributors to the Wiki, and you are loosing valuable contributions by keeping the Wiki locked down in read- only mode for everyone, including legit/old/well known contributors... Alternatively, you might ask your webmaster to add a banner to all Wiki pages for logged-in Wiki users, explaining that the Wiki is locked down and that they should open a support ticket to get it enabled in write mode for their account (of course, the support team might get swamped with requests, thus why I think the contributors grepping+whitelisting is a better solution). Best regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] SL Wiki locked down ?
Greetings, It's been three weeks that I can't edit any SL Wiki entry: was the Wiki locked down again ? If yes, then for how much time ? If no, then there's a bug... Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Replacement for QuickTime media plugin
Greetings, Callum suggested that this info would be forwarded to Oz, but since it is also of interest to the TPV developers at large, I'm posting it here for everyone's benefit. Note that Nicky also came with an additional argument in gstreamer's favour: as a stand-alone installation (instead of a bundle distributed with the viewer), it will get updated (either via the packaging system of the Linux distribution, or via its auto-updater for other OSes), ensuring all security holes/vulnerabilities are plugged over time, independently of the viewer version in use. Regards, Henri. -- Begin forwarded message: Date: Fri, 15 Jul 2016 23:00:14 +0200 From: Henri Beauchamp <sl...@free.fr> To: "Callum Prentice (Callum)" <cal...@lindenlab.com> Cc: "Nicky D." <sl.nicky...@googlemail.com> Subject: libVLC plugin Greetings ! It's been only a couple of weeks that I could look in details into the QuickTime plugin replacement issue, and at your viewer-vlc branch. .../... [edited out: no more relevant] Also, I had a fructuous exchange with Nicky Dasmijn last week: he got a gstreamer v1.0 plugin, and I got it working nicely in the Cool VL Viewer under both Linux (which already got a gstreamer v0.10 plugin) and Windows. It should also be possible to compile it with the MacOS-X viewer binaries. The BIG advantage of gstreamer over VLC is that it got a stable API and pre-built binaries for all OSes (Linux of course, but also Windows and MacOS-X), meaning you don't need to distribute any of the plugin codecs but *just* the plugin itself, saving about 200Mb of space in the viewer binary package ! Also, the potential (even if highly dubious) patent issue gets immediately solved, since it becomes the responsibility of the final users to install "patented" codecs or not on their system. In contrast, the libVLC plugin must be distributed together with all the VLC libraries and codecs/plugins, because the API changes almost with every new VLC version (I tried: even VLC v2.0 and v2.2 libraries are incompatible... I'm not even speaking about v3.0). By adopting gstreamer v1.0 in place of VLC, the users would just have to install a gstreamer distribution once and for all on their system (like it was the case for QuickTime under Windows, or gstreamer v0.10 under Linux), and the viewer binary bundles would stay slim enough. The gstreamer distribution is available here: https://gstreamer.freedesktop.org/ Also, the "pre-built library" package for compiling a gstreamer plugin only consists in header files (meaning no need for you to bother re- building gstreamer libraries for each OS), since the plugin loads its libraries and codecs only at run-time: much simpler than VLC ! .../... [edited out: flipping media texture issue, now solved] Finally, VLC (v2.1 and later) got its sound backend totally screwed up (for example, it won't work properly anymore under Linux with OSS as the sound driver), and its sound volume is also totally out of sync with the volume of other plugins (you'll need to push the VLC volume up to about 125% to get something equivalent to other plugins volume at 100%, but it's alas not even just an issue of a 1.25 multiplier: the volume difference in non-linear with other plugins). I would therefore recommend that you ask Nicky for his plugin and give it a try. I know I said on the list that I was pretty neutral between the VLC and the gstreamer plugins, but now, I definitely opted for gstreamer for the Cool VL Viewer (I can't afford wasting over one full hour uploading four 200Mb viewer packages at each new release, i.e. every week for my viewer)... Best regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Sat, 4 Jun 2016 06:52:58 -0500, Argent Stonecutter wrote: > > > • Ask for help from open source developer community to > create a version for Linux using LibVLC > > Since Linux currently doesn’t use Quicktime, why doe it need to be > converted? Quicktime media plays just fine under Linux, thank you !... It needs to be converted for the sake of having an uniform set of plugins with the same capabilities on all OSes... Also, the gstreamer plugin, while working just fine (again, for Quicktime media included), would need the viewer code to be changed (it's doable hoewever) if it would be kept along other plugins (the new CEF3 plugin, without media textures flipping, and now the VLC plugin), since media textures are flipped upside down when compared to the old way of rendering them (which matched the gstreamer, the Quicktime and the QtWebkit plugins). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Wed, 18 May 2016 13:49:26 +0200, Henri Beauchamp wrote: > On Wed, 18 May 2016 12:16:27 +0200, Nicky D. wrote: > > > It is supposed to be "Just add proprietary_codecs:1 to cef.gypi' > > That said there's probably the devil in the details, according to: > > http://www.magpcss.org/ceforum/viewtopic.php?f=6=10741 some > > had problems, but there's also a newer thread at > > http://magpcss.org/ceforum/viewtopic.php?f=6=13515 > > claiming success. > > I'll have a look, time permitting; I'm also in the process of migrating > my main system to a newer Linux distro and given the high level of > customizations I use (which involves recompiling many packages with > patches or different compile options), it will take time... Well, I finally got my new main system up and working (almost) fully the way I like, so I fired my CEF3 build VM (Debian 7.8 32 bits) and let it recompile CEF3 with the proprietary CODECs last night. I can confirm that it does build properly and results in a functional CEF3 plugin with MP4 & Co support (tested in a private build of the Cool VL Viewer, with the mime_types.xml file edited to replace all plugins with the CEF3 plugin): no more "You have requested a file download, which is not supported within the viewer." issue... Note that the CODECs are statically linked inside libcef.so (no need any more for a "ffmpegsumo" shared library). The rebuilt CEF3 package (without tcmalloc statically linked to it, and with the CODECs built-in) for 32 bits Linux is available here: http://sldev.free.fr/libraries/sources/ and the updated llceflib-linux-20160601.tar.bz2 32 bits package from here: http://sldev.free.fr/libraries/ The rebuild steps have been updated (basically, you need to install the "chromium" package for the CODECs headers/libraries and to add two variables to your .gyp/include.gypi file): http://sldev.free.fr/libraries/sources/cef-rebuild-steps-2526.txt I will also rebuild the 64 bits packages. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Wed, 18 May 2016 16:40:14 -0700, Callum Prentice (Callum) wrote: > Digesting all the suggestions here - thank you. > > Intrigued by Nicky's suggestion, I am currently trying to build CEF > directly via Chromium - first attempt is without the extra flags > (proprietary_codecs=1 ffmpeg_branding=Chrome). Building the branch in use > in the viewer failed with a bunch of errors - fixable but there were just > too many. Still not sure *why* it fails - I would expect specifying a > branch would chckout and build a tagged point in the repo that built. Welcome to the wonderful world of Chrome/CEF... It's indeed surprising to see how badly they screwed up the build system and what totally insane amounts of time (hours !) and efforts (manual patching) are required to build their browser (when Firefox builds flawlessly in under 20 minutes)... > Do people agree that this would be the best solution? Definitely NOT ! Please, see my prevous messages in this list (the last posted a few minutes ago). Please, pretty please, don't do that !!! Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Wed, 18 May 2016 21:49:46 -0700, Darien Caldwell wrote: > Using CEF for media is what I've been saying since CEF support was > announced for the viewer. I think it would be a clean solution. That solution would be plain *dirty* and totally wasteful (about 80Mb per new CEF plugin instance), it would also be a big issue for old computers and 32 bits OSes (and yes, there are still people using those, mind you !). Like I wrote in this list in an earlier message, using the CEF plugin to play streaming shared media is plain YUCK ! > The viewer already runs 3 instances of CEF at startup, Speak for your viewer... The Cool VL Viewer doesn't have any CEF (or QtWebkit, since it can also still use that one, for Windows XP users, who can't have a working CEF: the Windows CEF pre-built library is not compiled any more to support Windows XP...) plugin running unless there is a web media/UI element open. > using one of those for media wouldn't really add any additional load. You would need *one instance per shared media face*, not just one for all shared media around ! It would be tremendously wasteful of resources and would slow down things (CEF needs to refresh its frames 60 times per second, and it's not especially speedy when compared to a plain video stream played via gstreamer or VLC, the latter two also be playing the stream only at its native frame rate, never more). > The viewer is already using something else (FMODEX maybe) for MP3, as > it works without Quicktime installed. Yes, using FMOD Ex for playing plain sound shared media is an option, but since the latter are rather rare (audio streams in SL are usually played via the parcel streaming music channel), it would be acceptable to use gstreamer (which is not much more more wasteful than FMOD and is also, by designed, adapated to plain sound stream playin) or vlc (there would likeley be wome wastage here, since AFAIK vlc is primarily designed to play video streams). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Wed, 18 May 2016 12:16:27 +0200, Nicky D. wrote: > Point 1, bundling a lot of additional libraries probably also holds true > for libvlc. > One way or the other all those needed plugins need to end on the users PC, > no matter if it is gstreamer or vlc. True... I admit I didn't have a look at the vlc bundle for Windows. Under Linux, either won't be much of an issue, since all the necessary plugins/ CODECs packages will most likely already have been installed by default during OS installation. > ffmpegsumo might be another alternative, but this again needs building > Chromium. I was under the impression that ffmpegsumo got removed from recent CEF releases... Also, ffmpeg is, in my opinion and experience, an horrible pile of crapastic spaghetti... One version will more or less work with some media, and the next will crash lamentably... For example, ffmpeg v1.2 is much reliabler than (any, to date) v2 for *.ts (DVB-T streams) videos conversions... > I have a feeling at least for Linux gstreamer will be the easier one > to bundle (just rely on the installed gstreamer 1.0 installation on > the users machine). Well, the current plugin relies on gstreamer v0.10 and, in some Linux distros, v1.0 (when at all available) doesn't play well when installed along 0.10 (mainly because of a bad packaging from the distro maker)... That's in fact an argument against gstreamer, since most distros are (or have been) transitionning to gstreamer v1.0 and transition periods always lead to problems for the final user... > It is supposed to be "Just add proprietary_codecs:1 to cef.gypi' > That said there's probably the devil in the details, according to: > http://www.magpcss.org/ceforum/viewtopic.php?f=6=10741 some > had problems, but there's also a newer thread at > http://magpcss.org/ceforum/viewtopic.php?f=6=13515 > claiming success. I'll have a look, time permitting; I'm also in the process of migrating my main system to a newer Linux distro and given the high level of customizations I use (which involves recompiling many packages with patches or different compile options), it will take time... > I'd be interested in the resulting binary, maybe the ffmpeg parts > could really be reused for a media plugin without the need for either > vlc or gstreamer. > If you can share a Linux (x64 preferred) version, that would be most > welcome. I always make the Cool VL Viewer specific packages I use available on my website ( http://sldev.free.fr/libraries/ ) and you can bet that if I get CEF to compile with all plugins enabled, the resulting pre-built libraries will indeed be used by my viewer ! ;-) Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Replacement for QuickTime media plugin - a straw man proposal
On Tue, 17 May 2016 16:32:01 -0700, Callum Prentice (Callum) wrote: > Understood Nicky - thanks for the insight. > > Messages here as well as some digging I've done today suggest that > trying to make GStreamer work on Windows is going to be fraught with > technical and legal issues. Technical, maybe. As pointed out by Nicky, the main annoyances with gstreamer are: 1. the amount of additional libraries that would have to be bundled together with the viewer, and: 2. the runtime symbol resolution and DSO loading which complicates the plugin code, but since that plugin code exists already, point 2 is in fact already solved. As for the legal side, I see no difference between all possible solutions: should there be an issue with a particular CODEC because of patents, then this issue would be the same with vlc, gstreamer, quicktime, media player, CEF, etc, etc... > I'll double check with the legal team but it seems like VLC might be > a more viable option right now given our limited resources. I think that Nicky is mistaken by thinking that, because the LGPLed plugin code would have to use a GPL CODEC, then that CODEC DSO/library won't be usable: what counts, regarding the viewer code license, is the actual code of the viewer, not the license of the libraries that it uses (else, a GPL software won't be able to use Windows DLLs, for example, i.e. it won't be possible to use any GPL software on a closed source operating system). I do think your legal team provided you with the right answer: there is no issue whatsoever, be it gstreamer, vlc (or any other (L)GPL solution). This said, I'm pretty neutral about the final, adopted solution (gstreamer or vlc); I initially pointed gstreamer as "the way to go" because the gstreamer plugin code already existed and was functional (and is still used) for Linux, and pre-built gstreamer libraries/SDK also existed for Windows. My only wish is that the final solution will be adopted (and implemented !) for all OSes (Linux included) so that we get an uniform way to deal with media and avoid incompatibility issues (for example, in your vlc-enabled test viewer, you added code to invert upside down the media textures on shared media object faces, something that would be incompatible with the current gstreamer plugin). > Great idea re: CEF too - that'd be a huge win. Building Chromium > then CEF with the flags enabled seems pretty daunting though and I > think requires some serious hardware/RAM - has anyone tried that ? I did build CEF under Linux (for both 32 and 64 bits) because of the tcmalloc issue with CEF prebuilt packages for this OS; clearly, it was a major PITA... I was however unaware of these particular flags: if anyone could give me pointers (i.e. what flags to enable and how), I could give it a try and report how easy (or rather, how painful) it would be to rebuild CEF with them, and could provide you with a "recipe", like that one: http://sldev.free.fr/libraries/sources/cef-rebuild-steps-2526.txt Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quicktime
On Thu, 21 Apr 2016 19:45:29 +0200, Nicky D. wrote: > But when we're already on the topic of codecs and licenses, I think fmodex > might fall into the same category. It can decode MP3 and does not come > with a license for it: http://www.fmod.org/mp3license/ As I understand it, the phrases "Licensing FMOD products does not include a license to use mp3" and "Game developers using mp3 are eligible for the ‘game’ license which costs $2500 USD per title." just mean that *if* you are a game developer and are including MP3 encoded files in the game you sell, then (and only then), you might(*) have to pay a MP3 license to Thompson Multimedia and that *in no circumstance* does the FMOD license cover your MP3 usage. That's just a "disclaimer", not an interdiction to include FMOD in your product to play MP3 files... Since the SL viewer is not distributed with MP3 files (and only wav files are stored on LL's servers and served by LL to the viewers), this won't be a problem. Keep in mind that the shared/parcel media encountered in SL, are just URLs for files/streams stored anywhere on Internet but on LL's servers. (*) if you are a US/Canadian/Japan(?) citizen, *and* are distributing over 5000 copies of your game: this places me "out of the game" so to speak on both fronts (French citizen and probably less than 5000 users, not to mention I don't sell my viewer) ! :-P > Also if, and I am speaking purely hypothetical here, LL would ban Quicktime > and with that MP4 from their viewer and not have a alternate solution, I > guess the whole point is moot anyway. I suppose shipping those codecs and > being able to play those streams would be a shared experience violation then. Hehe, good one ! :-D Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quicktime
On Thu, 21 Apr 2016 02:50:13 +0100, Whirly Fizzle wrote: > Quite a few widely used SL TV sets still use quicktime media. Those > TV sets no longer play the movies now I've uninstalled quicktime > from my Windows box. Yep. > It appears LL are removing quicktime support from their viewer > https://bitbucket.org/callum_linden/viewer-release-noqt I already tried (months ago, when I noticed that the VS2012 builds were not producing a valid QuickTime plugin with the old QuickTime SDK) the trick consisting in replacing all occurrences of media_plugin_quicktime with media_plugin_cef (or even media_plugin_webkit; Webkit too, could play media, mind you...) in the mime_types.xml file for Windows, but got faced with the same problem as the one described by Nicky in the last commit to that experimental viewer (https://bitbucket.org/callum_linden/viewer-release-noqt/commits/540b99f9160fa478cade308f388e9303ed98b232) Many media URLs are then considered as files for download by CEF, causing a rejection of the URL and a failure to play the media. Plus, frankly, is it reasonnable to launch a new instance of CEF (i.e. a *full* embedded web browser instance, using over 80Mb of memory while the QuickTime plugin uses 100 times less) for *each* playing media on surrounding prims ? That's a bit like using a hammer and an anvil to squash a bug, don't you think so ?... Quite inelegant ! YUCK !!! Like I already wrote earlier, the way to go is to use the gstreamer SDK for Windows and get a gstreamer plugin compiled for the latter. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quicktime
On Wed, 20 Apr 2016 17:29:52 -0700, Darien Caldwell wrote: > Actually after more testing, I do see there's one last vestige Quicktime is > required for, and that's MP4 video streams. Won't work without it. Simply look at the mime_types.xml file: any URL type that invokes media_plugin_quicktime will fail if the QuickTime plugin (and Windows CODEC, which may be any QuickTime-compatible CODES, and not just the Apple QuickTime one) is absent. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quicktime
On Wed, 20 Apr 2016 10:49:04 -0700, Darien Caldwell wrote: > On Wed, Apr 20, 2016 at 12:39 AM, Henri Beauchamp <sl...@free.fr> wrote: > > > Yes, it prevents the viewer from reading media files, QuickTime's, > > but not only: all video and audio media files are read via the > > QuickTime plugin in the viewer: see the occurrences of > > "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml > > (for LL's viewer; some TPV moved this file where it truly belongs, > > in the app_settings/ sub-directory). > > > > > This is only true for old codebases. The modern viewer using Chromium > Embedded Framework no longer requires Quicktime. Quicktime was only used to > decode media streams. But the viewers now do this with the CEF codec. Nope !... Media URLs pointing to *.mp3/4g *.avi *.wav *.you_name_it_media_type *still* use the QuickTime (for Mac and Windows) or gstreamer (for Linux) plugin... There is confusion in many people mind's about media streams embedded inside a web page (which indeed are played via CEF now, provided the web page is using HTML5 or a proper CEF plugin exists for the embedded media stream) and raw media file URLs: the latter are *not* played via CEF. Just look at the code in llviewermedia.cpp... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Quicktime
On Tue, 19 Apr 2016 18:40:02 -0400, Andromeda Quonset wrote: > Now I am seeing a lot of messages urging all Windows users to > uninstall Quicktime, that it will never be updated for Windows, and > that it hasn't been updated for 10 years. So the first question is > "does uninstalling Quicktime have an impact on Second Life? Yes, it prevents the viewer from reading media files, QuickTime's, but not only: all video and audio media files are read via the QuickTime plugin in the viewer: see the occurrences of "media_plugin_quicktime" in skins/default/xui/en/mime_types.xml (for LL's viewer; some TPV moved this file where it truly belongs, in the app_settings/ sub-directory). > The second question might be 'do I still need the QuicktimeSDK for > compiling viewers? Yes and no. You can make it so that you compile a QuickTime-plugin-less viewer (this might require some changes to the cmake files for LL's viewer: some TPVs provide this choice as a build option, via a cmake define). Not sure if LL's viewer sources build "as is" without QuickTime. In any case, LL's latest viewers (late v3 and v4) require VS2012 to build, and VS2005/VS2010 QuickTime SDK is incompatible with VS2012 (the plugin will still build with the old SDK under VS2012, but the resulting binary will fail to launch). LL apparently got their hand on a VS2012-compatible QuickTime SDK (their VS2012-compiled viewer therefore got a functionnal QuikTime plugin, that you could reuse together with your QuickTime-less viewer builds). Alas, the corresponding pre-built library package is not available to the public (it is hosted on LL's private servers)... > Or is there some substitute by now? Not that I know of... I already pointed out (like years ago), in this very list that alternatives to the long deprecated QuickTime did exist and should be used by LL but, as usual, it felt into deaf ears (LL, once more: "I told you !"). Such an alternative could be the gstreamer SDK for Windows; after all, the gstreamer plugin already exists for Linux, so it should not be an impossible (or even difficult) task to extend its use to Windows builds of the viewer. The only "difficulty" is to create a proper pre-built library/headers package out of the SDK, which will include all the necessary dependencies to build and package the viewer. > In trying to find out more info about Quicktime, I find leads that > Homeland Security issued the warning. Then I find Homeland Security > copied a noticed from CERT, who copied a notice from Comodo.and > then I start having a few doubts about the warning being quite as > dire as I first read. As usual, such flaws require a thoroughly "cooked up" setup for a (black hat) hacker to exploit it against you. Whether it is possible to exploit QuikTime flaws to gain access to your computer via the QuickTime plugin is, for now and AFAIK, a purely theoretical issue. However, it is unwise to run exploitable software, even if the possibility of a compromission is slim. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] CEF3 64 bits for Linux
Greetings, TPV developers providing 64 bits Linux builds may be interested in my (tcmalloc-less) re-build of the CEF3 library and llceflib plugin for 64 bits Linux. See http://sldev.free.fr/libraries/sources/ for the CEF3 package (and build recipe, if you want to redo it yourself) and llceflib patch, and http://sldev.free.fr/libraries/ for the llceflib pre-built plugin. The binaries were tested and are working on Rosa 2012 and Ubuntu 12.04 distributions. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] USESYSTEMLIBS
On Tue, 15 Dec 2015 05:39:43 -0600, Nicky Perian wrote: > Anyone building using system libs .../... how are you handling the libs > that have no packages. jsoncpp glh-linear webkit hunspell to name a few. That's the problem with SYSTEMLIBS (AKA SATNDALONE in v1/2 viewers): you can't handle those missing depedencies using the default build system, making it a rather pointless feature of the said build system... A "long" time ago (8 years), I wrote a make-SL bash script (and later updated it to "cmake-SL" when the build system migrated from scons to cmake), that took care for copying selected (and selectable) system libraries (those actually present on the build system and which version was compatible with the viewer) and corresponding headers into the viewer's source tree own lib/ and include/ folders and which updated the installed "lock" (more like flag) files to fool the viewer's build system into believing it already had downloaded and untared the corresponding pre-built packages. The script also removed the corresponding viewer_manifest.py script lines that were responsible for copying the pre-built libraries and packaging them with the viewer. Then the script launched a non-SYSTEMLIBS/non-STANDALONE build, the build system then only downloading and untaring the pre-packged libraris that were not already pre-populated by cmake-SL, causing the resulting viewer binary to be compiled and linked with the system libraries and packaged without them. I am still using that script for personal builds, but LL's viewer since parted from the Snowglobe build system which my viewer is still using (i.e. I'm not using "autobuild" at all), so it won't be suitable for your particular use case... The true and final solution for that problem would be to use differentiated "_SYSTEMLIB" defines in the viewer cmake files, so to be able to specify the system/pre-packaged choice for *each* individual library/package. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Viewer Azumarill (coroutines) issue
Greetings, Last week, I started backporting viewer-azumarill's coroutine code to the future experimental branch (v1.26.17) of the Cool VL Viewer. I first concentrated on backporting only the llcorehttp "coroutined" code and the related services (i.e. texture fetchs, mesh repository, AIS and HTTP inventory fetches). Alas, the resulting viewer kept crashing after each AIS request was being cleaned-up. I lost a lot of time incriminating my own backport and searching for something I would have missed in Azumarill's diff, but in the end, I had to conclude that the problem was with the llcorehttp coroutine implementation itself. Today, I worked again on that issue and narrowed down the problem to a bogus call to a destroyed HttpRequestPumper. It looks like the LLTempBoundListener associated with an HttpRequestPumper destroys the latter just before the call to "mainloop.post(new_frame);" per-frame pumping (in llappviewer.cpp) and that the event pump didn't yet register the destruction of the said HttpRequestPumper, thus wrongly calling its pollRequest() callback (causing a segfault in the latter). Not having signed a CA, I won't post here the code I used to work around that problem (in llcorehttputil.cpp), but here is the comment I wrote for it, which explains it all and could be used with benefit by LL: /// // HttpRequestPumper class /// // The HttpRequestPumper is a utility class. When constructed it will poll the // supplied HttpRequest once per frame until it is destroyed. // NOTE: I had to change the pollRequest() method for a static one and keep // track of the existing HttpRequestPumper instances in a list so that, when // called, pollRequest() checks that the corresponding HttpRequestPumper // instance does still actually exist. This is because there is a fatal issue // with so many boost "smart" pointers that get deleted in an order that we do // not control, the result being in a poll request sometimes happening (always // under Linux, at the completion and dequeuing of AIS requests) while the // corresponding HttpRequestPumper just got deleted (probably via the // LLTempBoundListener boost::signals2::scoped_connection), causing a segfault. // LL should really stop using boost stuff so much... It's becoming insane: // obfuscating code complexity behind a gazillion of templates does not make // the code cleaner (and certainly not faster), much to the contrary ! HB Note that depending on the plateform/OS (or even compiler version and optimisations) you compiled viewer-azumarill on, you might not encounter the issue I hit, but there is an issue with the reliability of the whole code, because of the uncontrolled and pretty much random sequence of templatized structures destructions. I think more thinking is necessary, before calling the current coroutine-based code acceptable. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Windows surprise build error
On Sun, 29 Nov 2015 21:02:32 -0600, Nicky Perian wrote: > Last night everything built w/o error. > Today this is happening. > Has anyone seen this? > > 12>-- Build started: Project: lscript_compile, Configuration: Release > Win32 -- > 12> Building Custom Rule > C:/Users/Bill/398-buildcleanup/indra/lscript/lscript_compile/CMakeLists.txt I'm surprised that LL didn't yet get rid of the whole lscript_* source tree in their viewer... It's been *years* that it became totally useless (scripts have been compiled server side for almost as long as the viewer sources were made open by LL), excepted for the LSL function definitions and tooltips (in lscript_library), but even those are now deprecated and not used any more... You can get rid of that source tree, or simply remove the reference to it from the indra/CMakeList.txt file... This also removes any dependency to flex for compiling the viewer: problem solved ! :-D Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] CEF plugin for Linux and VS2010 builds
Greetings, Here is an update about CEF3 for Linux and Windows VS2010 builds. Since the (VS2013) Windows plugin moved to CEF v3.2526, so did I for the Linux and VS2010 plugins. You will find: - The rebuilt CEF 3.2526 Linux package (identical to the package from https://cefbuilds.com/ but built without tcmalloc) here: http://sldev.free.fr/libraries/sources/ There is also a text file (cef-rebuild-steps-2526.txt) with the recipe for rebuilding CEF3 yourself, if you really want to loose your time (3H of download, 12H of compilation, quite a few quirks...). - The llceflib packages for Linux and Windows/VS2010 here: http://sldev.free.fr/libraries/ (there is also a repackaged MacOS-X package, identical to LL's but with fixes to llceflib.h (structure/class members shall not be initialized in the structure/class declaration !!!) that allows gcc to compile it: useful if you are still compiling viewer binaries with older Xcode versions which made use of gcc). - The diff showing what needed to be modified in and added to LL's llceflib in order to build the Linux and VS2010 versions here: http://sldev.free.fr/libraries/patches/ - The diff between the non-CEF and CEF versions of the Cool VL Viewer, here: http://sldev.free.fr/patches/CoolVLViewer-CEF-diff.txt I hereby license anything I put there as LGPL code, reusable by anyone if they so wish. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Debugging purging a single folder from trash
On Sun, 4 Oct 2015 21:50:39 -0700, Ricky wrote: > Just a quickie, trying to avoid digging through the viewer code myself to > be sure: > When a folder that is in the trash is purged, what calls to the server does > the client make? > > I'm debugging an OpenSim derivative, I don't know what you are trying to debug, but just in case, be aware that at least one such "derivatives", in use on OSGrid, does not obey the purge trash messages sent by the viewer (it looks like the trash gets emptied, but on relog, the purged items will reappear in it): it's totally weird and IMO a pure non-sense but in OSGrid, if you want to purge your trash, you must login into their web site and purge it from there... I myself lost quite some time (G !) trying to figure out why I couldn't purge my trash (and searched pointlessly for a bug in my viewer), till I found out this totally quirky (and unique: I didn't encounter it on any other grid) "feature" of OSGrid. > and just noticed that it seems that > there's a difference in the calls when the folder being purged has children > and when it doesn't. Trying to confirm that there is an actual difference > or if something else in this complex system is interacting... The relevant call in the viewer code is remove_inventory_category() (in llviewerinventory.cpp). When connected to a non-AISv3 (which is the case for OpenSIM), it either sends to the server a single RemoveInventoryFolder UDP message when the folder is empty or, for each child folder (recursively, via the destructor of the LLRemoveCategoryOnDestroy class), a PurgeInventoryDescendents UDP message (via purge_descendents_of()) followed with a RemoveInventoryFolder UDP message; the process is recursively repeated till the purged inventory folder is empty (at which point a last RemoveInventoryFolder message is sent for the purged parent folder). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Debugging purging a single folder from trash
On Mon, 5 Oct 2015 16:52:05 +0200, Latif Khalifa wrote: > It's not nonsense, it's a security measure. In SL sims are trusted so > they proxy all the communication from the viewer to the central > services such as inventory and assets. On OSGrid anyone can attach > their own sim. This sim could tell the inventory service "User XYZ > just emptied the trash", which in practice means everyone with a > modified sim code could empty your Trash and Lost & Found. > > This is why those operations were disabled on OSGrid, and work just > fine on more controlled grids. So, instead of securing the communications (simply check that the user is actually logged into the requesting sim, or use AISv3 instead of UDP messages), you prefer breaking a protocol (not even documenting the change anywhere, and not warning the TPV developpers you did it)... Non-sense (again) ! Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Debugging purging a single folder from trash
On Mon, 5 Oct 2015 17:33:03 +0200, Latif Khalifa wrote: > AISv3 is new. I backported it to the Cool VL Viewer back on 2014-03-15... Not *that* new any more. > There is no "upstream" to port from (like viewer devs do). Also this > restriction is on one grid only. Join #opensim-dev on freenode if > you want to ask people about current limitations of OpenSim. If you guys break protocols that were specified by LL for SL, or create new protocols, and wish having the viewers supporting your sims, I'd suggest you to use an "information push" approach, instead of awaiting for TPV developpers to "pull" info from you. I always tried to support OpenSIM to the best in my viewer, but it has always been a big PITA, due to the total lack of documentation and information from OpenSim developers. 'nuff said. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] CEF plugin for Linux and VS2010 builds
Greetings,
Here is an update about CEF3 for Linux and Windows VS2010 builds.
Since the (VS2013) Windows plugin moved to CEF v3.2454, so did I for
the Linux and VS2010 plugins.
Again (as usual ?), rebuilding CEF3 v3.2454 (without tcmalloc) under
Linux proved trickier than rebuilding the previous version... This
time, you may get a random error when building CEF v3.2454, because
of the parallele building process and a missing dependency on a
dynamically generated header file, sometimes causing a race
condition.
Also, v3.2454 now makes an heavier use of the C++11 standard (use of
"override" and "final" class qualifiers, but not only). In order to
build the Linux and Windows VS2010 plugins you therefore need
gcc v4.7 for Linux and a patch to cef_bind_internal.h (redefining
"final" as "sealed") for VS2010.
Note that, thankfully, even though the Linux plugin was built with
gcc v4.7, you can still link it without any issue with viewer
binaries compiled with gcc v4.6 ("thankfully", because gcc v4.7 is
known to fail to produce viewer binaries that link properly with the
boost libraries), and run it with libstdc++ v6.0.16 (i.e. you don't
need a system with gcc v4.7 and libstdc++ v6.0.17 installed).
However, CEF v3.2454 for Linux makes use of glib functions that only
appeared in glib v2.32, adding a tighter dependency for target
systems (the viewer itself working with glib v2.28 or newer) when
compared with v2.2357.
You will find here: http://sldev.free.fr/libraries/ the llceflib
packages for both Linux and VS2010.
Finally, have a look here: http://sldev.free.fr/libraries/patches/
to see what needed to be modified in LL's llceflib and CEF3.
I hereby license anything I put there as LGPL code, reusable by
anyone if they so wish.
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] CEF plugin for Linux builds, a recipe
Greetings, Here is an update about CEF3 for Linux (and Windows VS2010) builds. Since the (VS2013) Windows plugin moved to CEF v3.2357, so did I for the Linux plugin (it will not be said that Linux got inferior support than Windoze ! :-P). Note that rebuilding 3.2357 is even trickier than for 3.2272, mainly because of bugs in CEF3's and LLVM/clang/compiler-rt building systems. If you are definitely, irremediably, masochistic, and want to rebuild it yourself, then I wrote down a recipe, available here: http://sldev.free.fr/libraries/sources/cef-rebuild-steps.txt If you don't want to loose your time reinventing the wheel then you can just grab the rebuilt package from here: http://sldev.free.fr/libraries/sources/cef_binary_3.2357.1281.gd660177_linux32-no_tcmalloc.tar.bz2 I could also produce a VS2010 llceflib (meaning you won't need to update your TPV to use the new build tools for now). You will find here: http://sldev.free.fr/libraries/ the llceflib packages for both Linux and VS2010 (I'm not using a link to the packages themselves, because they might change every week, following the progresses on the CEF3 media plugin implementation). Finally, have a look here: http://sldev.free.fr/libraries/patches/ to see what needed to be modified in LL's llceflib so to implement it under Linux and make it compile under Windows with VS2010. I hereby license anything I put there as LGPL code, reusable by anyone if they so wish. Note that the llceflib version for Linux is now compiled on a clone of my usual build system for the Cool VL Viewer (I'm using a clone because I wanted to keep the original build system for non-CEF builds, so to avoid having them poisonned with stricter library version dependencies). That clone got the necessary updates to libX11, libXi and libnss3, so that CEF3 can be properly linked. Users of old (4+ years) Linux systems may still run the resulting binaries by adding to the viewer installation lib/ sub-directory a few libraries that I packaged and made available from here: http://sldev.free.fr/libraries/ See also the announcement on the Cool VL Viewer forum for details about what works and what still doesn't work in llceflib (Lindens might be interested by it too...): http://sldev.free.fr/forum/viewtopic.php?f=5t=1543p=7112#p7112 For people curious about how CEF3 fares when compared to QtWebKit, I released the Cool VL Viewer v1.26.15.0 today for this purpose (use the new UseCEF debug setting to switch between QtWebKit and CEF without even the need for a viewer restart). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Building GTK+ and friends with autobuild new tools
On Thu, 23 Jul 2015 21:47:36 -0500, Nicky Perian wrote: Thanks for taking time to provide a thoughtful reply. I agree, it is not a viewer for older distributions. I don't consider 3 years old distributions as old ones... If you do, then What would you say about Windows XP, Vista, or even Windows 7 ? :-D However, by packaging libstdc++ with the viewer lib/ it runs very well on debian jessie (current stable), Ubuntu 14.04 and Linux Mint 17.1 and 17.2. and several other distributions. Try Ubuntu 12 (2012, i.e. 3 years old only)... Or Mandriva derivatives Mageia, Rosa, OpenMandriva, etc, most of which had their two last releases published in 2012 and 2014 (the 2014 release will work, not the 2012)... I consider that, for any given distribution, at the very least the two releases that came before the current one should be able to run my viewer. Kokua linux 64 bit test viewer build with these libraries has been out for several weeks and there are with very few problems reports. Opensuse being one of the few. IMO if you run opensuse w/KDE you might as well install windows. Pardon ?... I'd never run Windows. And no, I'm not using KDE either, but even KDE users would not drop Linux for Windoze. :-P Telling to OpenSuse users, hey, just use Windows instead to run my viewer ! is just as lame as Linux support drop by LL... You don't want to become as lame as LL, do you ?... :-D Here is a code snip from one of the libraries .../... All of the gtk and friends libraries will build on gcc-4.6. Just change 4.9 to 4.6 atthe beginning of the linux sections of the script. This is not *just* a problem with gcc... You need to provide pre- built glib and gtk ( ancillaries) versions which are *inferior or equal* to the ones of oldest distribution you want the viewer to run onto, else you will invariably get unresolved symbols at runtime, because neither glib nor gtk are packaged with the viewer (which therefore uses the libraries of the system it is ran onto). Also, you need to make sure that the glibc version of the system you build your pre-built libraries onto is old enough to run on the oldest targeted distribution. To give you an example, software such as Firefox, Google Earth, VirtualBox, Blender etc (i.e. software that come as, or are also available as non-distribution specific packaged binaries, just like SL viewers) can all run on a glibc v2.11 system (my oldest Linux system runs them), and perhaps even older (I won't be surprised if they can still run on a glibc 2.10 system). Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Building GTK+ and friends with autobuild new tools
On Wed, 22 Jul 2015 13:08:16 -0500, Nicky Perian wrote: Removed use_prebuilt_binary(gtk-atk-pango-glib) archive. Replaced with: glib-2.44.1-linux-201507131131.tar.bz2 I'm afraid these are way too modern libraries... My main Linux system, which runs a distribution released in 2012 (i.e. not even yet 3 years old) still uses glib v2.28... It means that any viewer built on that new a set of libraries will fail to run on all but *very* recent Linux distribution releases... cairo-1.14.2-linux-201507192252.tar.bz2 atk-2.16.0-linux-201507162046.tar.bz2 pango-1.36.8-linux-201507201400.tar.bz2 gtk-2.24.28-linux-201507211717.tar.bz2 gdk_pixbuf-2.30.8-linux-201507210933.tar.bz2 pixman-0.32.6-linux-201507192238.tar.bz2 Here, I got: - cairo v1.10.2 - atk v2.0.1 - pango v1.29.4 - gtk2 v2.24.10 - gdk_pixbuf v2.24 - pixman v0.22.0 Not that I'm too worried about those for my own viewer, since I got entirely rid of the GTK ancillaries dependencies many months ago (I'm using an XUI-based, fully OS-independent (and natively non- blocking) file/directory selector, rewrote the whole copy/paste text routines and based only on Xlib, and I'm using a wrapper script calling any of Xdialog/Zenity/xmessage/etc to replace the GTK box (OSMessageBox()) used in case of viewer launch failure). But for other viewers still using GTK, the same remark as for glib holds true, I'm afraid... use_prebuilt_binary(harfbuzz) Wazzat ??? O.O The libraries are built with gcc-4.9.2 as is Kokua. Which, again, is an excessive system requirement on both glibc (v2.13 here) and libstdc++ versions... LL's pre-built libraries have all been compiled with gcc v4.6 and can run even on glibc v2.11 (and probably even older, but I don't have an older system to test the viewer onto :-P). You should keep using gcc v4.6.4 for building Linux libraries. For your info, my current build system for the Cool VL Viewer dates back from 2010 (gcc 4.6.4, glibc v2.11.1 and libstdc++ v6.0.16). Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] VS2013 viewer builds and llqtwebkit
Greetings, I updated my viewer so that it could be built with VS2013 (in excess of VS2010), but I'm having troubles with LL's llqtwebkit library: when VS2013 attempts to link media_plugin_webkit against that library, the linker spits error messages such as: llqtwebkit.lib(llqtwebkit.obj) : error LNK2038: mismatch detected for '_MSC_VER': value '1600' doesn't match value '1800' in media_plugin_webkit.obj Strangely enough, and although I'm using the very pre-built llqtwebkit package that is linked to in LL's latest release viewer (new build tools) autobuild.xml file, the library doesn't seem to have been built using VS2013... Did anyone else run into this issue (i.e. is anyone else than LL actually compiling their viewer with the new build tools), and/or did anyone already compile themselves llqtwebkit with VS2013 (I'd gladly borrow their binary, since I'm busy enough already with CEF3 stuff) ? Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] CEF plugin for Linux builds, a recipe
). In viewer-cef's indra/cmake/CEFPlugin.cmake file, the Linux CEF_PLUGIN_LIBRARIES must account for the fact that, if not told otherwise, ld will garabage-collect the linked static libraries (libcef_dll_wrapper.a and libllceflib.a), and since those contain functions that are interfaces to (and also called by) libcef.so, but are not called from the CEF plugin itself, ld will fail to retain these functions, causing unresolved symbols errors to spawn at run time. You must therefore ensure that the static libraries are included whole, by enclosing them between -Wl,-whole-archive and -Wl,-no-whole-archive linker directives. In viewer-cef's indra/media_plugins/cef/media_plugin_cef.cpp, be careful again with the filename case in the #includes... In order for CEF to find its resource files (icudtl.dat, *.pak files and locales, but also the *_blob.bin files which made their appearance in CEF 3.2272), SLPlugin, media_plugin-cef, llceflib_host, chrome-sandbox and all the resource files and locales directory shall be kept in the same sub-directory. Else, the icudtl.dat and *.pak files will first be searched in the directory where SLPlugin resides, then in the one the other executables (sandboxes, media-plugin) reside... I solved this issue for my viewer by moving SLPlugin from the bin/ sub-directory into the bin/llplugin/ sub-directory, and installing all the CEF3 resources there as well. In order for CEF to find its sandbox, you will need to add to the newview/linux_tools/wrapper.sh file a couple of exports (one for the PATH, including bin/llplugin/, and one for the CHROME_DEVEL_SANDBOX variable, pointing to the chrome-sandbox executable in bin/llplugin/). VOLUME 3 ( or was that CHAPTER 3 ?... :-P ): first impressions on CEF * 1.- Dependencies. Unlike QtWebKit, CEF3 (and more accurately, libcef.so) depends on MANY system libraries (try ldd libcef.so...), and it means that it will be harder for 64 bits Linux users to get a 32 bits viewer to run on their system (they will have to watch the unresolved symbols error lines on a console and install the corresponding 32 bits libraries on their system... I could cite, from memory, ORBit2, libgio, libgamin, libcap, libxtst, libnss, libnspr, and quite a few others... all of which were not needed for 32 bits viewers using QtWebKit... You also need a system with a recent libX11 (v1.4 or older won't suffice and you'd get a _XGetRequest unresolved symbol) and a recent libXi (v1.6 or newer) with XITouchClass implemented. My Rosa 2012 system (released in 2012 as its name implies) still had libX11 and libXi v1.4 and I therefore got unresolved errors at first. The good news is that libX11 abd libXi updating doesn't involve updating the whole X11 shebang, but it still excludes all but the one and half year old or so Linux distros (unless their user knows how to update and rebuild themselves some of their distro's packages). The rendering by CEF3 is MUCH SLOWER than what we get with QtWebKit (the SL v3 login page will typically take from 30 seconds to 1 minute (!) to load, when only a dozen of seconds, at worst, were enough for QtWebKit to render it). I'll have to investigate this further, since I think I remember about an issue with WebKit (and even before that, with mozilla when it was used for the built-in browser) that involved the plugin eating up a full CPU core (and IIRC, that was solved with a sleeping mechanism that could perhaps get in the way now with CEF). The font rendering by CEF3 is mediocre, to say the least (especially for small size of fonts), but it might be a problem with how the viewer uses fontconfig for itself. This will have to be investigated as well prior to any release... There's apparently a bug that causes CEF3 media to render upside- down on prims with shared media... Here are a few screen shots I took with the Cool VL Viewer in both QtWebKit and CEF3 modes: http://sldev.free.fr/pictures/CoolVLViewerCEF.png http://sldev.free.fr/pictures/CoolVLViewerWebKit.png http://sldev.free.fr/pictures/CoolVLViewerCEFV3Login.png http://sldev.free.fr/pictures/CoolVLViewerWebKitV3Login.png http://sldev.free.fr/pictures/CoolVLViewerCEFMedia.png http://sldev.free.fr/pictures/CoolVLViewerWebKitMedia.png As a last note, and interestingly, if you are curious enough, you will notice that CEF3 is built upon... WebKit !... That pretty much makes it a bloated WebKit, and one could wonder if it won't be more efficient to update/develop further QtWebKit than to adopt CEF3, which seems to be having quite a few issues still to be solved... In the hope it will help. Henri Beauchamp. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Tools Upgrades - with a call for help
On Fri, 27 Feb 2015 09:23:19 -0500, Oz Linden (Scott Lawrence) wrote: On 2015-02-24 17:10 , Henri Beauchamp wrote: On Tue, 24 Feb 2015 15:37:21 -0600, Nicky Perian wrote: Plugins are no longer built in the viewer but, are delivered as content in an archive. Which means TPV developers will not be able any more to fix bugs in the plugins and will have to endure the very same bugs as the ones plagging LL's viewer... Not at all - the repository that builds the plugins is public. https://bitbucket.org/lindenlab/3p-update-slplugins And I confirm my assertion.. See by yourself: that link points to a repository which holds only *binaries* (no source at all !): how would TPV developers fix bugs and provide/use fixed binaries without the sources ??? that will move to 3p-slplugins when we release the tools update viewer (which should be going to release candidate very shortly). Not at all... The proper and only clean solution would be to get fully rid of the Quicktime dependency for the builds... Quicktime is totally outdated anyway. I see no reason to remove support for any Quicktime content people may have in SL if we can avoid it. You may perfectly read Quicktime encoded files using other libraries (including open source ones) than that old Quicktime SDK... All what I said is that it is time to drop that old Quicktime for Windows SDK and use another (preferably an open source one) instead. We are very actively working on updating the web media subsystem; whether or not it will maintain exactly the current plugin strategy, and whether or not it will be possible to keep Quicktime working are still to be determined. Stay tuned. Glad to know there's work being done... I'd wish it would be done in the open however... Any chance to get a public repository open for the current work in progress ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Tools Upgrades - with a call for help
On Tue, 24 Feb 2015 19:03:29 -0800, Darien Caldwell wrote: I'm pretty sure the reasoning behind LL moving all the multimedia to a plugin system was so that 3rd parties could write their own plugins. I doubt it... There's nothing stopping anyone from writing a plugin to take over all the functions the old Quicktime plugin does. It's just that nobody has bothered to do it. Don't count on me: I never use the multimedia features myself (if I want to watch a video stream, listen to music or browse a website, I do it with the proper, dedicated programs out of the viewer itself... I keep doing things the UNIX way, i.e. using the right, specialized program/tool for each special purpose). However, since LL has concentrated in the past months on improving and attempting to fix things that don't work properly, I'm simply pointing out one such thing that would need a serious rework: the whole multimedia thing is completely outdated in the viewer... Quicktime is old, the current version is still compiled for Windows XP, and Apple seems to have abandoned it. Exactly, thus why it's (more than) about time to drop it completely ! With HTML5, it's pretty much unnecessary in this day and age. Someone should just write a new Parcel media plugin and put quicktime to bed for good. HTML5 is just a different way to embbed multimedia contents in a web page. It still relies on OS-dependent renderers that are now however taken care of by the web browsers (using existing multimedia libraries for each OS) themselves rather than via third parties plugins. So, HTML5 support won't save LL from implementing proper multimedia support in the viewer itself (and would require using a built-in browser plugin that also supports HTML5, which is not the case of the current QT Webkit plugin), and parcel media is *not* the *real* problem here... Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Tools Upgrades - with a call for help
On Tue, 24 Feb 2015 15:37:21 -0600, Nicky Perian wrote: Plugins are no longer built in the viewer but, are delivered as content in an archive. Which means TPV developers will not be able any more to fix bugs in the plugins and will have to endure the very same bugs as the ones plagging LL's viewer... Sory, but this is a *bad* solution. For quicktime this is more licence friendly by delivering the dll instead on the components needed to build the dll in the viewer. The SDK can still be downloaded from Apple's site (or was the last time I checked), so where is the problem exactly ?... That is likely not the complete reason for packaging but, it is cleaner. Not at all... The proper and only clean solution would be to get fully rid of the Quicktime dependency for the builds... Quicktime is totally outdated anyway. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Avatar Hover Height feature
On Tue, 3 Feb 2015 20:11:40 +0100, Zi Ree wrote: On Dienstag, 3. Februar 2015 20:00:13 Henri Beauchamp wrote: and only if, I do not have to disclose my snail-mail address and phone number, both being beyond the purpose and requirements of a license agreement and being private data I won't give up for such a purpose To sign over your rights on the code they need to have a legal person on the other side. You. My address and phone number are not needed to establish the legal person condition: all they need is my real name and signature on the document, which I'm ready to provide them with. To show you how ridiculous the address and phone number requirements are, I'll just say that I moved already 5 times in my life and changed at least 8 times from phone number !!! Not only this information is subject to change at any time but none of the signees of LL's License agreement are required to inform LL about their address of phone number changes. Legally, all what is required to establish an identity from a document is the name and signature it bears. The rest is excessive for the purpose, something the French Law Informatique et Liberté forbids to require from a signee. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Avatar Hover Height feature
On Wed, 4 Feb 2015 03:50:08 +0100, Carlo Wood wrote:
However,
sometimes I wonder why you aren't being smarter than this :p
Probably because I'm more stubborn than I am smart... :-P
I don't give-up easily when I know my way is the right way to
achieve a given result.
Linden Lab ('s internal coders) hadn't even LOOKED at our
contributions and EVERYTHING we did had been /dev/null-ed and
not used in their next release. I didn't reconfirmation: I left.
Yes, it is exactly what I meant by waste of resources in my last
message... It saddens me to no end when I see talented programmers
giving up on SL because of LL's stance... The first one, of fond
memories, was Nicholaz Beresford... It was before Oz' era too.
At the time I was enthusiastic about working on an opensource
viewer (even though that meant given my private info, which I
agree is rather silly and annoying; and I understand why you
refuse that)... That was before Oz .../...
Bottom line is. Linden Lab only uses and likes invented here.
The don't listen to others, nor are they interested in what
others have to say.
Yes, it has been a constant in LL's stance, and Oz is therefore not the
(only) one to blame. LL's policy towards Open Source is simply
inadequate and harmful... for themselves !
It is obvious and perfectly normal that LL must have the last word and
make the final decision on SL's working and features. However, it is a
pure waste of grey matter resources to dismiss or ignore proposals and
just oppose a the factors .../... are quite complicated as an excuse
for it, not even caring to discuss the matter, and first starting to
expose their constraints and what complication(s) they encounter. We
(the Open Source developers) may surprise them and come up with a
solution they didn't think about... That's the whole point of
collaborative work !
.../... Trying to communicate with Linden Lab is a waste of your time.
This is alas all too often true. However, sometimes, communication works
(see the AO example I cited yesterday in my last message on this list).
Thing is, I cannot infer from the various communication experiences with
them a way to make sure my next proposal will be taken into account in
a constructive fashion by LL... Their reactions to proposals are at best
described as chaotic !
Stop Wasting Your Time. Just let them kill SL in peace.
It's not a total waste (the waste only happens when trying to
communicate with LL and they don't listen/care).
I like SL a lot. I love programming. It's fun as far as I am concerned.
I also like challenges and I like to use my brain to solve problems.
This said, should I get tired of it all and stop having fun in SL
(because I'm a roleplayer too, and enjoy roleplaying in SL), then I'll
definitely give up.
Also, I took the Your World, Your Imagination motto to the letter,
and Lindens should perhaps be reminded that motto from time to times...
PS Needless to say that I completely agree with the technical point you
have been making. But it's not just the hover height that is
problematic lol. The whole animation (format) is useless.
The format lacks a single parameter: what bone (or more likely joint)
shall stay in contact with the ground when a given standing (i.e.
when the avatar is root and not seated on a prim) animation is played.
We could call this parameter the contact bone/joint.
For a kneeling anim, it would be the knee joint, for a laying anim,
it could be the shoulder joints or the spine bone, for a standing
anim, the feet, etc...
This could be one of the improvements in SL 2 (it's too late for SL 1)
*if* LL already thought about it, or *if* they read this message...
.../...
The main problem with both is that it only works for a static pose,
not for an animation where the knees are bend and stretched again,
like in certain dance animations, or in animation where someone goes
from standing up to a (ground) sitting pose for example.
You are perfectly right... and the height adjustment indeed can't
suffice in the case of complex animations. One of the solutions (for
SL 2), still retaining the contact bone/joint idea I described above
would be to allow this reference to be changed on a per-frame basis.
Note that the server-side contact bone/joint implementation would
be quite complex and involve a much smarter physics engine or a
much more complete description/implementation of an avatar in that
engine (instead of dealing with a bounding box and its center
position, the physics engine would have to deal with every avatar's
bones/joints).
Regards,
Henri.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Avatar Hover Height feature
On Tue, 3 Feb 2015 08:53:12 -0800, Harold Brown wrote: The simple fact of the matter is. If you do not sign a code contribution agreement LL can NOT use your code. The code is (L)GPL. Anyone can reuse it and even if it had been my intention (and it never was and never will), I can't oppose to have my code reused (by anyone !) after I got it (L)GPLed. That's the whole point of the (L)GPL !!! As for an additional safety measure (lawyers' paranoia, obviously) such as a License agreement, I have always been ready to sign one if, and only if, I do not have to disclose my snail-mail address and phone number, both being beyond the purpose and requirements of a license agreement and being private data I won't give up for such a purpose (like the French Law allows and even encourages me). Oz knows that already. Anyway, it was not even question to reuse my code in the SUN-38 issue, for there was no code of mine (it's mostly server side stuff, anyway). It was just question of a suitable protocol definition so to address the actual issue behind SUN-38 (the avatar bounding box issue, even if a *side-effect* of being able to change the bounding box in the Z axis also allows to adjust the animations height and thus to address as well the animations issues). There has been at least one example in the past of a *great* and *benefical* discussion about a protocol definition (for Animation Overiders), you can see the archive for the corresponding thread here: https://lists.secondlife.com/pipermail/opensource-dev/2012-April/008850.html and my main contribution to it here: https://lists.secondlife.com/pipermail/opensource-dev/2012-April/008850.html a contribution which apparently was the base for the final protocol that LL implemented (which was finally 100% server-side (via scripts) and did indeed address all the points I raised), and a contribution for which I was thanked by Oz in an email. I had the hope the SUN-38 issue could have been dealt with with the same cleverness and efficiency... Failed ! It's beyond my comprehension that LL can't seem to be able to make use of the programming power and competences brought to them *for free* by OpenSource developers, and instead prefer to take the most arrogant stance and discourage them. What an incredible waste of resources !!! Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Avatar Hover Height feature
On Mon, 02 Feb 2015 13:05:20 -0500, Oz Linden (Scott Lawrence) wrote: On 2015-01-31 07:53 , Henri Beauchamp wrote: Greetings, I know this should be posted in the JIRA, but apparently the comments in the existing issue (SUN-38) are not read or not taken into account by Lindens. Please, to any and all Linden(s) involved in AHH, do read this post for your own enlightement (and hopefully, a better and definitive solution for the SL community as a whole): http://sldev.free.fr/forum/viewtopic.php?f=5t=1494p=6890#p6890 Note that I'm beyond the point to care about whether this message will be taken into account or not (so it's perfectly useless to enter a sterile argument on this list about it). It's more like a bottled message I throw into the sea... I won't speculate on whether or not we would have decided to do it differently had your suggestion actually been made when we were starting work on this months ago; the factors affecting avatar height and avatar vertical offset are quite complicated and it may or may not have been the right thing to do. I will say that your input would certainly have been considered had you been a part of the conversation at the time rather than posting a note on our private forum well after the fact. Are you ***kidding*** me I have been attending quite a few Server group meetings with Nyx, and you even were there once (for sure) or twice (can't swear on it), when I spoke about the SUN-38 issue. You will find several agendas with my entry about SUN-38, in the Wiki: http://wiki.secondlife.com/w/index.php?title=Special%3ASearchsearch=henri+sun-38fulltext=Search Most of the corresponding transcripts are alas missing from the Wiki, but I *did* explain my solution in at least two of those meetings and I will point out one particular agenda, where I asked if SPEAKING with a Linden about SUN-38 and the possible solutions would be at all possible: http://wiki.secondlife.com/wiki/Mesh/Archive/2013-04-29 It's not my fault if you keep shrugging off every remark or proposal I make, or even refuse the dialog (in plain text, because I cannot articulate well enough English neither understand English spoken with the US American accent in real time). I will not even bother quoting the various emails I sent to *YOU*, Oz, and that you never replied (albeit about other subjects than SUN-38), but if you want them, I could dig in my backups... Despite the fact that you refuse to contribute your code, Again you are reverting the roles here I never refused to contribute my code: it's GPL and always said that anyone (and yes, that includes *you* Lindens) could reuse it. Also, each time someone asked for permissionto make my code LGPL to be compatible with their own viewer, I always said go for it !. What I refuse, however, is to sign a contribution agreement where I would have to give private data to perfect strangers residing in a foreign country that doesn't respect the privacy protection Law of *my* country (or of any other country for that purpose). You perfectly know this, for I explained it to you (and to Soft Linden, your predecessor) countless times in emails, even going down to give you pointers to paragraphs in the (English- translated even !) French Law Informatique et Liberté. I am not the one refusing to contribute my code, YOU are the one(s) refusing to use my contributions because of stupid and pointless lawyer-induced bureaucracy. It is *YOUR* choice and *YOUR* refusal, not mine !!! I'm happy to make sure that your input is considered if and when you provide it in a timely way; I am the very initiator of the SUN-38 issue, and if you re-read the comments I made in it, my solution is exposed here as well (see the comment posted on 22/Jun/14 10:58 AM, in reply to the Firestorm team's proposal, i.e. QUITE in the TIMELY manner !!!). I ALWAYS gave pointers to major flaws and regressions, either in the form of a JIRA issue, or directly via emails (to YOU !!!). So, accusing me of not providing the info or not in a timely manner is quite INSULTING and a pure LIE from your part. I hope that in the future you'll chose to engage more productively. I hope that in the future, you will actually read the JIRAs I initiate, the emails I send to you, the messages I post on the various boards and blogs you DO frequent as well as I do (Nalate's blog, to cite just one). I also hope that you will make the minimum effort to communicate in a way that a non-English speaking person such as myself can actually manage (Open Source meetings used to happen in CHAT and not in voice, when Soft Linden was still there... and I DID tell you in one of your first meetings that people like me COULDN'T attend your meetings because of the language barrier: I can find the log, if you wish...). Now, I would *much* more prefer a clever and fruitful collaboration to this sterile childish behaviour (ignoring me, then putting the fault on me for not participating
Re: [opensource-dev] Viewer Tools Upgrades - with a call for help
On Thu, 29 Jan 2015 14:06:17 -0800, Callum Prentice (Callum) wrote: Yep - we need to add the right set of parameters to 'autobuild' to set up FMod, Havok QuickTime etc. Can anyone tell me what they are or point me at the right doc before I start searching. I can't help you about the autobuild system itself, because I only build the Cool VL Viewer (v1 UI viewer with v2/3 code I backported to it), and it doesn't use autobuild at all... When building it, I first run a winprebuild.bat batch script that I wrote and that simply takes care of copying the FMOD Ex files in the viewer sources tree lib/ and include/ (and newview/, for the dll itself) directories. Here is the relevant part of the batch script: rem Copy of the fmod headers and libs: set FMOD_DIR=C:\Program Files\FMOD SoundSystem\FMOD Programmers API Windows xcopy /y %FMOD_DIR%\api\inc\* ..\include\ copy /y %FMOD_DIR%\api\lib\fmodex_vc.lib ..\lib\release\ copy /y %FMOD_DIR%\api\lib\fmodexL_vc.lib ..\lib\debug\ copy /y %FMOD_DIR%\api\fmodex.dll newview\ The FMOD Ex package for Windows can be found here: http://www.fmod.org/download/fmodex/api/Win/fmodapiNwin-installer.exe where N is the version number (44450 as I'm writing this) and the download page with up to date links to the files is: http://www.fmod.org/download-previous-products/ (notice the previous... It means that FMOD Ex is going to be phased out... Any plan from LL to replace it in future viewers ?). For Quictime, VS2010 (I didn't yet try with VS2013) and cmake do find the SDK by themselves (so there's no need to copy the libraries and include files like needed with FMOD Ex). I don't have a ready-made URL for the Quicktime SDK (the TPV builder will have to register an Apple's devel account, log in and dig into their site to find the old Quicktime v7.3 SDK... It'd be about time LL would find a way to get media working under Windows without having to use that (long) deprecated Quicktime SDK...). As for Havok, not all TPVs can use it (obviously, genuine (L)GPL TPVs can't)... I'm using HACD to replace the Havok library for mesh decompositions, and I simply don't have the pathfinding capsule and path rendering tool implemented. Regards, Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] TPV Wiki page locked ?
On Sat, 11 Oct 2014 20:02:00 +0200, Henri Beauchamp wrote: On Sat, 11 Oct 2014 19:44:50 +0200, Martin Fürholz wrote: http://status.secondlifegrid.net/2014/10/07/post2378/ Ah, yes, that would explain it... Thanks ! Is the Wiki maintenance still in progress (after a month, it'd be surprising), because I still can't edit in it... Did someone forget to flip back the switch on, at LL ? Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] TPV Wiki page locked ?
On Sat, 8 Nov 2014 11:24:18 -0500, Jonathan Welch wrote: I asked Oz about this the other day. All wiki pages are still locked with no time frame for when the underlaying security issues will be addressed. -jonathan Thanks for the info. Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Did that new CDN break web profiles for all TPVs?
On Sat, 08 Nov 2014 21:21:59 +0100, Lance Corrimal wrote: Hi, is it just me, or did that new CDN break webprofiles for all viewers that don't have some new code for it? Working fine here (France) in the Cool VL Viewer, including with a one year old release that didn't have the newest llqtwebkit library neither the new pipelining stuff (albeit the latter won't affect the built-in web browser used by the web profiles). In Dolphin Viewer 3 Beta as well as in FS all I see is plaintext, links in profiles don't work anymore, no graphics; as if the stylesheet is missing. In the original viewer from get.secondlife.com and in a binary built from the latest viewer-release export the profiles work just fine, and if I go to someone's profile in firefox using http://my.secondlife.com/lance.corrimal it loads fine, too. Any suggestions? Perhaps a problem with your local CDN cache... That is, if profiles do use CDN at your location. Here, 'nslookup my.secondlife.com' reports: my.secondlife.com canonical name = profiles-production-2-1922215598.us-west-2.elb.amazonaws.com. Name: profiles-production-2-1922215598.us-west-2.elb.amazonaws.com Address: 54.245.247.187 Name: profiles-production-2-1922215598.us-west-2.elb.amazonaws.com Address: 54.245.106.156 Name: profiles-production-2-1922215598.us-west-2.elb.amazonaws.com Address: 54.214.14.37 So, I'm apparently not hitting a CDN server when loading a web profile (AFAIK, CDN is only for meshes and textures, in SL). Try configuring a proxy (outside your country) for the web connections in the viewer, and see if it makes any difference. Oh... and do clear your viewer's web cache (in case a truncated/corrupted CSS file is cached there and messes up everything). Henri. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
