• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
MAINTENANCE ANNOUNCEMENT - JIRA will undergo maintenance starting 1:00am PDT through 3:00am on Saturday 2010.03.20. Please do not enter issues during this time as the system maybe restarted.
Issue Details (XML | Word | Printable)

Key: SVC-5005
Type: New Feature New Feature
Status: Open Open
Priority: Normal Normal
Assignee: Unassigned
Reporter: TigroSpottystripes Katsu
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

new data type: rawbits

Created: 07/Nov/09 04:49 PM   Updated: 07/Nov/09 04:49 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified


 Description  « Hide
this data format would be composed of zeros and ones, of variable length like strings and lists (as much as can fit in the script memory)

(rawbits)astring would either convert the string into raw bits if the string is composed only of 1's and 0's, or no bits at all if there is anything else, same thing for integers

(string)arawbits would result in a string composed of zeros and 1's in the exact order they are in the rawbits, or an empty string if there are no bits

(integer)arawbits would result in literal trensplantation of zeros and 1's, would look the same if either is converted to string, except for any zeros to t he left of the last 1s, but if there are no bits it would still become the integer 0

to do actual bit by bit conversion between types, there would be llRawbits2* and ll*2Rawbits functions that would see the bits as bits on all data types. For the data types that got a fix number of bits, like integers, the llRawbits2* functions would have a parameters for the beginning bit, if it runs out of bits, the remaining bits are zero. If it's necessary to have a valid format, like valid UTF* encoding for strings, if the rawbits are not in the right format, return a constant.

Just about all operations that can be done with integers should work with rawbits, but there would be no wrapping around if the value goes bigger than DEBUG_CHANNEL. There would also be functions like for lists and strings, for finding and replacing groups of bits. There would also be functions for inserting/overwriting N copies of a group of bits (somthing like llRawbitsPatternFill(rawbits destrawbits, rawbits sourcerawbits, integer startpoint, integer repetitions, integer insertoroverwrite) ) if the repetitions go beyond existing bits, they create new ones, and if it's set to insert isntead of overwrite, existing bits past the start point are bumped to the next bits to fit the fill pattern. Ideally there should also be a function to reverse the order of the bits.

Perhaps the llRawbits2* functions should have a begin and end parameters, at least for the ones to formats that don't require a fixed number of bits.

To reduce the bit count, there is no need to add an additional command, just use the replace or pattern fill command and replace some bits with an empty rawbits pattern (I'm not sure which character(s) would be used to surround rawbits typed int he script, but whatever is chosen, to make an empty rawbits just do it like for empty strings and lists, or perhaps don't delimit rawbits, but represent an empty rawbits by a single decimal point (the little dot used on floats) with no digits on either side)

Perhaps use the decimal point as the delimiter char, while also allowing additional points in the middle, if there is either a digit, or another point touching it's not the end of the rawbits group ( both . and .. would be empty rawbits, and .10. and .1.0.0.110.01.0.0....10011.. etc would all be valid rawbits). When just assigning a value, the points in the middle are ignored, but when replacing or doing pattern fills, whenever an inner dot is present, the bit it replaces/overwrites is deleted and the bits surrounding come together. Though I'm not sure how exactly the void bits would be stored int he rawbits, perhaps they can't really exists, and we just use a single . for empty rawbits and never together with any digit or other points as described above and no interleaved deletion.

ps:I'm not sure if I'm missing anything for the moment, this might not be the final deifnition, and of course, I'm open to suggestions



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
There are no comments yet on this issue.