Hy Nyx,
I have used this in the Green Emerald viewer - IT IS VERY useful, ie
especially when you need textual input from a lot of users, but don't want
those individuals to see others input - ie: Quiz games.
If you download the green emerald viewer, you can put this script in it to
test it out:
i
Hey, this patch came up in office hours - it could be pretty useful for
a lot of people.
There's a patch attached to the JIRA, does anyone have some time to
evaluate its usefulness / functionality and get a code review to work it
into snowglobe?
-Nyx
__
You'd be better working off the Snowglobe branch at the moment which is more up
to date. This and other issues compiling the viewer on the Mac with GCC 4.2 and
against the 10.5 or 10.6 SDKs have already been fixed. See
http://jira.secondlife.com/browse/SNOW-210 for this one.
As far as I'm aware
Sorry, obvious correction needed: An LLSD map is a
std::map
On Wed, Nov 4, 2009 at 7:18 AM, Kelly Linden wrote:
> LLSD has two container classes, maps and arrays. The LLSD map is a
> std::vector, while the LLSD array is a std::vector.
> These are both pretty much standard STL, wrapped to be LLS
I see an LL_DARWIN, is there one for specific releases?
I am adding specific to intel OSX things, and want to have them only
be in Intel builds, for example Leopard and Snow Leopard are Intel
only. Second there are places where there are checks for old (pre
10.4). I'd like to know if there are to
LLSD has two container classes, maps and arrays. The LLSD map is a
std::vector, while the LLSD array is a std::vector.
These are both pretty much standard STL, wrapped to be LLSD based.
LLSD my_array = LLSD::emptyArray();
my_array.append(5);
std::cout << my_array[0] << std::endl;
You need to wal
-Werror is supplied by the make files. This too involves changing
code, and is a bad idea in open source, since it gets people to check
problems before submitting them as patches.
Better here, I think, would be to make this opaque, rather than having
constant strings in cpp files that the code han
Lillian Yiyuan wrote:
> You can tell the nice people developing the gcc that they made a
> mistake enforcing type checking then. However, you've provided no
> evidence that your position is based on any kind of knowledge.
>
> On Wed, Nov 4, 2009 at 5:55 AM, Argent Stonecutter
> wrote:
>
>> Whic
You can tell the nice people developing the gcc that they made a
mistake enforcing type checking then. However, you've provided no
evidence that your position is based on any kind of knowledge.
On Wed, Nov 4, 2009 at 5:55 AM, Argent Stonecutter
wrote:
> On 2009-11-04, at 07:34, Lillian Yiyuan w
On 2009-11-04, at 07:34, Lillian Yiyuan wrote:
> As I understand what is going on, it is definitely a vulnerability to
> have a pointer to a fixed string being handed out as if it is a
> variable. You can get rid of it by the flag for no write strings,
> which is one of the options. But I don't kno
As I understand what is going on, it is definitely a vulnerability to
have a pointer to a fixed string being handed out as if it is a
variable. You can get rid of it by the flag for no write strings,
which is one of the options. But I don't know enough about the problem
to say which of the choices
On 2009-11-03, at 12:30, Lillian Yiyuan wrote:
> That produces the same error. I suppose the question is whether the
> variables should be const char to begin with, but I don't know enough
> about them to know whether they are modified, and thus don't want to
> change the definition. The error also
12 matches
Mail list logo