On 11/09/2010 08:12 AM, Ricky wrote:
> Trying to compile viewer_development a60d3b118c76 (tip as of the time
> of this message) I get the following error:
>
> make[2]: *** No rule to make target
> `sharedlibs//PROJECT_llmath_TEST_llbboxlocal', needed by
> `llmath/PROJECT_llmath_TEST_llbboxlocal_ok.
I think of it as "frsutrate". I especially like it when they don't know I
have block/mute/ignore them.
On Mon, Nov 8, 2010 at 6:18 PM, Yoz Grahame wrote:
> ... or Esbee's original suggestion, "Block", which is easily the most
> common term for this across social software UIs. I just checked a
I think the filename needs to be based on the unique account name, with any
periods (.) replaced by underscore (_).
The display names can change weekly, and as you note it would be much more
difficult to track based on display name.
Q
On Nov 8, 2010, at 11:45 AM, Oz Linden (Scott La
On 11/09/2010 04:39 PM, Kent Quirk (Q Linden) wrote:
> The display names can change weekly, and as you note it would be much
> more difficult to track based on display name.
Even worse when it'd happen (though probably much less likely to occur),
two people might have the same display name at the s
Maybe is the right time to implement in LSL sort of llKey2Name, save logs
and other using the UUID and cache the display name (at least 1 change per
week us allowed, caching username and display name should solve ??? Problem,
falling back on cached if trouble)
--
Sent by iPhone
Il giorno 09/nov/
As a user, I would expect if i log itno the secondlife website and then try to
get some live support, it would then automatically connect me under the account
I am logged into the website under and not any of say the last 4 or five
accounts that logged in from this computer...
Is that really to
On 2010-11-09 12:04, Erin Mallory wrote:
As a user, I would expect if i log itno the secondlife website and
then try to get some live support, it would then automatically connect
me under the account I am logged into the website under and not any of
say the last 4 or five accounts that logged i
On Tue, Nov 9, 2010 at 1:04 AM, Boroondas Gupte
wrote:
> On 11/09/2010 08:12 AM, Ricky wrote:
>
> Trying to compile viewer_development a60d3b118c76 (tip as of the time
> of this message) I get the following error:
>
> make[2]: *** No rule to make target
> `sharedlibs//PROJECT_llmath_TEST_llbboxlo
*Tuesday, November 9, 2010*
*General Notes*
- Merge Monkey of the Day: Oz
- If an issue is “In Progress” it should have a time estimate!
- Please remember - when merging your fixes into Beta, you must also pull
them into viewer-development immediately after
- If you take a bug of
Just a note -- since the XCode tools are free, high quality, and supported,
Linden Lab is unlikely to put any significant prioritization into making other
toolsets work on the mac. If someone else wants to add such support without
breaking what we have, then we won't gratuitously break it, but w
USER STORY
As an amateur developer, if I try to generate a makefile based environment
on OS X, I would expect a warning to tell me that this is not supported.
comment: Isn't this just one or two lines in develop.py?
ponzu
On Tue, Nov 9, 2010 at 3:09 PM, Kent Quirk (Q Linden) wrote:
> Just a
The issue then is that the default generator for simply running "cmake
." is makefiles. May I suggest then that since the build system makes
assumptions about the default generator on each platform, that the
default generator be selected per platform? Then the "fast and easy"
method for a develop
To add to my journey here, now that I know I need to use Xcode when
compiling on a Mac, I did the following:
cmake -G Xcode .
xcodebuild
And I get the following errors:
2010-11-09 20:21:30.629 xcodebuild[35776:80b]
CFPropertyListCreateFromXMLData(): Old-style plist parser: missing
semicolon in di
13 matches
Mail list logo