You are not logged in.
Pages: 1
{
var l1, l2, s1, s2, sr, n, hex;
hex = "0123456789ABCDEF";
l1 = argument0; l2 = argument1;
s1 = ds_list_write(l1); s2 = ds_list_write(l2);
sr = string_copy(s1, 1, 8);
n = ds_list_size(l1) + ds_list_size(l2);
repeat (4) {
sr += string_copy(hex, ((n & $f0) >> 4) + 1, 1)
+ string_copy(hex, (n & $0f) + 1, 1);
n = n >> 8;
}
sr += string_delete(s1, 1, 16) + string_delete(s2, 1, 16);
ds_list_read(l1, sr);
return l1;
}
Takes two lists as arguments and appends the contents of the second list to the first.
Offline
Pretty sneaky.
Abusing forum power since 1986.
Offline
What is?
Offline
Abusing the ds_list_read/write functions like that. It's just entirely too diabolical. I like it. Looks to be very fast for GM7 users.
Done any testing for accuracy and speed?
Abusing forum power since 1986.
Offline
No, I haven't tested its speed at all. I don't know what you mean about accuracy, though. This won't lose any accuracy.
I really wish GM used Base64 instead of Hexadecimal for these strings, though. Hexadecimal is too big.
Offline
Well, you're exploiting an undocumented feature. I think this needs to go through some trials to determine if it works reliably.
This technique might be a fast way to do general hex conversions, at least for large amounts of data. ASCII conversion seems to be a no brainer, but how are numbers stored? IEEE-754 to hex?
Abusing forum power since 1986.
Offline
It's almost a straight memory dump but in hex. Here's a little text file I cooked up back when I decided to figure the format out for use from a DLL. It's quite a verbose format, which is why I'd prefer base 64.
All of GM's data structure's seem to output what is essentially a hex encoded memory dump of the
data structure. This means that all integers and doubles are encoded in little-endian format.---------------------------------------------------------------------------------------------------
list, stack, queue:
Offset Size (b) Information
0x00 4 DS identifier (see below)
0x04 4 (int) number of elements in structure
Element record
{
0x00 4 Indicates whether element is a string (1) or real (0)
0x04 8 IEEE 754 double
0x0C 4 (int) Length of following string field (0 if not present)
[0x10 (0x0C) bytes contained in string (only present if previous field != 0)]
}
---------------------------------------------------------------------------------------------------
map, pqueue:
Offset Size (b) Information
0x00 4 DS identifier (see below)
0x04 4 (int) number of elements in structure
Key/Priority record
{
0x00 4 Indicates whether element is a string (1) or real (0)
0x04 8 IEEE 754 double
0x0C 4 (int) Length of following string field (0 if not present)
[0x10 (0x0C) bytes contained in string (only present if previous field != 0)]
}
Value record
{
Same as above
}Maps store their keys in order first. Then the values are recorded in order. For keys, real
values come before strings. Priority queues are similar in that the priorities are stored before
their associated values, however the priorities are unsorted and show up in the order that they
were added to the queue.
---------------------------------------------------------------------------------------------------
grid:
Offset Size (b) Information
0x00 4 (0x59020000)
0x04 4 (int) width
0x08 4 (int) height
Element record
{
0x00 4 Indicates whether element is a string (1) or real (0)
0x04 8 IEEE 754 double
0x0C 4 (int) Length of following string field (0 if not present)
[0x10 (0x0C) bytes contained in string (only present if previous field != 0)]
}Elements are stored in column-major order.
===================================================================================================
Identifers:
list: 0x2D010000
stack: 0x65000000
queue: 0xC9000000map: 0x91010000
pqueue: 0xF5010000grid: 0x59020000
Last edited by Yourself (2008-07-15 16:24:50)
Offline
Wow, the similarity of these structures would appear to make transformations between different types a snap. It looks like a real and string could be stored in the same record. Am I reading that correctly?
Abusing forum power since 1986.
Offline
Yes, both a real and a string can be stored in a record simultaneously. However, I don't know why that's useful since you'd only be able to access one from GM. Additionally, the type identifier might cause it to only load the correct type and just ignore the other.
One thing you could do is transform a bunch of lists into a grid or vice-versa where each list is a column. It also allows you to quickly slice lists and change them between stacks and queues. However, I think some people used that trick a long time ago (but just supplying the entire string into the read function of a different data structure, rather than reformatting it).
Offline
Pages: 1