Second Life Wiki - User contributions [en]

Talk:LlGetFreeMemory

2007-06-28T22:54:04Z

Num Skall: New page: --~~~~ Each script is presently allocated a 16K page of memory which contains the LSO bytecode, heap and stack. This function returns the difference between the current stack pointer and t...

--[[User:Num Skall|Num Skall]] 15:54, 28 June 2007 (PDT) Each script is presently allocated a 16K page of memory which contains the LSO bytecode, heap and stack. This function returns the difference between the current stack pointer and the heap's high-water mark. If the heap is exhausted, the stack and heap will collide and the '''script will crash'''.<br><br>
If one is running low on memory, consider splitting the script into two parts or attempt to simplify the code. This includes strings as well (''War and Peace'' should probably be placed in a notecard and not a string constant). Remember that every byte saved in code gives you one more for the heap and stack.

LSL Switch Statement

2007-04-20T19:18:04Z

Num Skall:

''This article is a feature request''

The ability to use something like the following:

Switch (''variable'')
case ''condition 1'':
Do something;
break;
case ''condition 2'':
Do something;
default:
Do something;

Note: Isn't LSL all server-side? I don't think this can be implemented in the client. - [[User:Ihavegot Wood|Ihavegot Wood]]
:LSL is run on the server yes, but the compiler is in the client. LSO wasn't designed with switch statements in mind so some changes to the VM would be required, just wait for Mono. [[User:Strife Onizuka|Strife Onizuka]]

This is not entirely accurate ... LSO has branch instructions (aka GOTO) which is all that is needed to implement ''switch'' constructs and the ''break'' and ''continue'' statements. Basically, it's just an issue of adding these statements to the compiler and ensuring the code generator emits the proper LSO instructions. Besides updating the grammar itself, I'd personally like to see the use of ANTLR (see [http://www.antlr.org]) over the current Flex/Yacc/Bison implementation. Provided that LL isn't already in the process of implementing this, I would not be adverse to doing so myself. --[[User:Num Skall|Num Skall]] 12:07, 18 April 2007 (PDT)

:The issue is that LSL is a stack based language, the act of doing a conditional jump pops the condition off the stack, unless something special was done for switch statements there would be no performance improvement over complex conditional structures. If you are willing to write the code to implement this, the LSL compiler is open source. Of course when the LSL is ported to Mono we won't have to use LSL to write scripts for SL. I'm still trying to decide if I'm going to use Managed C++ or C#. Either way I get switch statements without LL having to do anything. -- [[User:Strife Onizuka|Strife Onizuka]] 18:51, 18 April 2007 (PDT)

:So? The issue isn't performance improvement but, rather, simplicity and readability of the LSL code. As for LSO being stack based, that's also a non-issue. My current projects are exactly like that too. Besides, having ''break'' and ''continue'' statements are the real benefit here. Think of how that would improve looping constructs. Properly done, the resulting object code efficiency will be the same. I'll get the source installed and see just how much is going to be involved. The first step will be converting to use of ANTLR to get the benefits of a full LRL rescursive-decent parser (makes code generation from the parse tree oh so much easier). It also generates the Lexical Analyzer from the same grammar file. Win-win. -- [[User:Num Skall|Num Skall]] 12:18, 20 April 2007 (PDT)

[[Category:Feature Requests]]

Talk:Web Textures

2007-04-18T20:21:59Z

Num Skall: Literature

{{Open Source Talk Page}}

Argent, Lets try to keep these article-like, rather than discussion-like. I integrated your comments.

On the white/black list pros and cons, instead of commenting on them, put a subpoint under them to say what would mitigate that con, or just take the con out if you think it's completely bogus. [[User:Gigs Taggart|Gigs Taggart]] 09:54, 26 January 2007 (PST)

Done -- [[User:Argent Stonecutter|Argent Stonecutter]] 12:18, 26 January 2007 (PST)

Gigs, the discussion of privacy concerns needs to be in a separate section. [[User:Argent Stonecutter|Argent Stonecutter]] 06:42, 31 January 2007 (PST)

== Making page moves ==

Please make a request to make a page move rather than making moves by cutting/pasting (just request on [[User talk:Rob Linden]] for now...we'll come up with a more streamlined process later). It's really a pain to merge histories after a cut/paste/redirect move, and much simpler to move the history/discussion and everything in one move. Thanks -- [[User:Rob Linden|Rob Linden]] 10:40, 26 January 2007 (PST)
:Turns out there is a move tab I overlooked. I'll use that from now on. [[User:Gigs Taggart|Gigs Taggart]] 11:37, 26 January 2007 (PST)

== Proxy ==

If a professional can't type in an IP address and port number, they aren't very much of a professional. [[User:Gigs Taggart|Gigs Taggart]] 16:51, 26 January 2007 (PST)

have you ever used an anonymizing proxy chain? -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:38, 28 January 2007 (PST)
== Streaming Media ==
Streaming music is not specific to the "Do Nothing - Just Implement It" section. I've restored that section. Comments about the relationship between streaming media and texture bugs need to be outside any specific section. Here's my thoughts on it:

Yes, streaming media is an issue. There have been scares in the past over streaming media, and for that I've been on the side of "don't worry about it". Why?

Streaming media differs from texture bugs:
* A significant number of people do not use streaming media in SL because:
** The overhead of streaming media has an impact on performance.
** A lot of people have really bad music on their land.
* Streaming music is limited to one parcel. Texture bugs can be anywhere.
* The bandwidth costs of any large streaming-media-based collection scheme are significant.

The result is that it's a far less significant exposure: fewer people are impacted, and even for those people you can only collect data in a small number of places. -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:49, 28 January 2007 (PST)

::Sorry, I undid some of your changes before I saw this. I reorganized the article some to reflect this suggestion. [[User:Gigs Taggart|Gigs Taggart]] 12:00, 29 January 2007 (PST)

== With regards to LSL Implementation ==

Implementation could be simplified thusly:
Instead of the original code:
<pre>
llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);
</pre>
<pre>
llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llRefreshTextureURL(integer face);
</pre>

We can make use of llSetTexture()'s ability to be supplied with either a string OR a key.

<div style="font-size:140%"><pre>
llSetTexture("http://example.com/example.png",ALL_SIDES);
</pre></div>

Since the LSL/Mono VM first checks if the variable supplied for the texture name is in the object's contents, after checking if it's a UUID, the VM would check if it's a valid URL.

''I like that idea. This could also be applied to llRenderHTML and llRenderText in [[Programmatic Textures]] by allowing the string to be well-formatted XML or the name of a notecard in the objet's inventory'' -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:31, 31 January 2007 (PST)

An alternate method, if Linden Lab were to host/cache the images so the Asset system information could be used to enable Copyright owners to stop content from being used:

<div style="font-size:140%"><pre>
llSetTexture(llExternalAsset("http://example.com/example.png"),ALL_SIDES);
</pre></div>

llExternalAsset() would take any valid URI, and return a UUID that could be used with the appropriate existing LSL function. Any header information found in the file can be applied to the Asset system, so if a web page/image/sound/animation/etc. had creator/author/producer/developer attributes attached to it, the Asset Server will store that information, so it will be displayed in the UI (as opposed to the uploader of content in the current fashion). This would also give copyright holders an avenue to pursue DMCA claims, as the hypothetical system would indicate that they are owner, making things easier except for cases whereby the less scrupulous Resident did something like run an image through the GD libraries to strip out the metadata.

The llExternalAsset() implementation would also benefit greatly from caching, for two reasons:
# You'd obviously not want a new asset to be created every time the script was restarted.
# Lots of people might use the same resource, and
## this would help lower the amount of duplicate information being stored
## this would speed up subsequent queries
### In cases where the Asset Server indicates that the external asset already exists in the system, it'll have the option of attempting to receive a HTTP 304 header from the external source, or
### If one location for the asset is bogged down, the current simulator's local asset server can make the call and supply that image to the local simulator.
###* In this instance, after the local simulator re-downloaded the texture, binary comparison would have to be executed, and if the local sim's texture is different to the other sim's textures, then the other sim's asset servers would replace the old asset with the freshly downloaded one.

[[User:SignpostMarv Martin|SignpostMarv Martin]] 07:20, 29 January 2007 (PST)
::Creating assets for every frame of dyanmic content isn't really even an option. A web cam might be streaming 5 images a second through this. You are assuming that this would be for static images. That defeats the entire point of it. They can just upload the image if it's static. This is not some "save 10L on the upload fee" gimmick, the entire point of this is scriptable dynamic content. [[User:Gigs Taggart|Gigs Taggart]] 11:54, 29 January 2007 (PST)
:::Yeah, but someone streaming a webcam would be better off using the parcel media stuff.
:::Would you be willing to pay for each asset you create with this method ? L$10, L$20, L$30 ?
:::[[User:SignpostMarv Martin|SignpostMarv Martin]] 12:43, 29 January 2007 (PST)

::Linden Labs has already ruled out any scripted generation of assets. -- [[User:Argent Stonecutter|Argent Stonecutter]] 06:32, 31 January 2007 (PST)

::I'll second Gigs' point; this isn't about saving a few cents, it is about immediacy of near-live or live content, and as such no client should be seeing cached content, otherwise we're back to working out how to get multiple residents 'see' the same display concurrently (which inho is the reason for needing web xxx on a prim) --[[User:Alison Wheels|Alison Wheels]] 03:53, 28 March 2007 (PDT)

:I'd like to avoid conflicts with inventory & urls and adding new functions. Since pipe is an unusable character in inventory names, I suggest it be used at the start of URIs. <code><nowiki>llSetTexture("|http://www.example.com/example.jp2", ALL_SIDES);</nowiki></code> [[User:Strife Onizuka|Strife Onizuka]] 11:37, 28 March 2007 (PDT)
::By not having new functions we remove the complicatsions of what [[llGetTexture]]/[[llGetPrimitiveParams]] should return. But it is probably better to add new functions. [[User:Strife Onizuka|Strife Onizuka]] 21:24, 28 March 2007 (PDT)

== Possible problem with feature ==

The way a image has to be intepreted relies on header data.
This header data indicates to the viewer/interpreter info like howmuch data is being send, the pixeldepth etc.
Deliberated corrupted headers could pose new and unpredictable problems.
Also the threat of hiding executable data inside an image might create new types of threats.

I'd like it if someone with some insight on this issue would describe which implementations of this feature would pose the most risk.--[[User:Vernes Veranes|Vernes Veranes]] 05:59, 28 March 2007 (PDT)
::You'd be surprised how little data validation the server does on uploaded textures. This is really not a new issue, the client must handle corrupted and even malicious textures right now, even without web textures. [[User:Gigs Taggart|Gigs Taggart]] 21:19, 10 April 2007 (PDT)

==Texture/Bandwidth Theft==
One problem with allowing unrestricted access to any (viable) texture on the web is that of using the materials and bandwidth of unsuspecting hosts. One solution is to require that any texture to be used must have, in the same directory or one higher up the parent tree, a text file of a particular name (such as "secondlife.txt") in much the same way that the "robots.txt" file is used.

Such a file could also contain information restricting what objects can use that texture in the form of a ban or allow list. References could include a UUID along with Owner, Creator, Group, or to get really specific, a particular Role in a Group. Failure to match these rules results in the 404 texture.

: This is a hot linking issue. It's simply a case of adding an appropriate value into the referrer header. Thus requiring no extra text-files to be added, and making the "bandwidth theft" prevention methods 100% compatible with every existing installation of a hot linking preventing script, whereby the referrers must match a specific URL or domain.
: [[User:SignpostMarv Martin|SignpostMarv Martin]] 14:15, 10 April 2007 (PDT)
::This is completely not an issue. The chance that someone is hosting a power of 2 texture that is a TGA or Jpeg2000 is nil. You can't just use random images off the net for a web texture, they will have to be specially crafted for this purpose. [[User:Gigs Taggart|Gigs Taggart]] 21:18, 10 April 2007 (PDT)

== Literature ==

Another use which springs to mind is that of literature. Presently, providing a magazine, book or other publication in-world requires rendering each "page" into a texture and uploading these individually. I can forsee SL "publishers" using PERL/PHP cgi-bin scripts to convert page-sized chunks of text and/or rendering pages from PDF files. Though issues of copyright are of concern, the benefits to SL residents would be enormous.
-- [[User:Num Skall|Num Skall]] 13:21, 18 April 2007 (PDT)

LSL Switch Statement

2007-04-18T19:07:50Z

Num Skall:

Talk:LSL Switch Statement

2007-04-18T17:41:49Z

Num Skall: It's do-able

Speaking from experience, implementing a ''switch'' statement is within the purview of the compiler's parser and code-generator. To implement such requires only comparison and both conditional and unconditional branching support within the Sim's interpreter. The same applies to ''break'' and ''continue'' statements as well.