• 0

    posted a message on LibCompress
    Quote from OrionShock
    Link above the comments section "See tickets on CurseForge" takes you to the ticket place on either site, from there i just hit back to project or what ever i need :D


    Ah yes, I used that once, but forgot about it. Thanks for the reminder.

    And what is it with curse.com and the extreme delay on approving new downloads? Is there another site that is more reliable? wowinterface.com maybe?
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    I know, but at least they could provide an easy link to the edit-page.
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Requires that I am on wowace already ;-) but I am visiting the LibCompress on curse.com. Anyway, I found a way that requires only 5 (five) clicks... Why it has to be hidden so far away is beyond me.

    Anyway, I updated the page with a usage description of LibCompress. Go nuts! :)
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Quote from ciscoh
    curse uses the project description used here on wowace. edit it here, and it will update curse.com


    Same problem. Then I have to visit wowace.com and find the project here and then edit. No different than curseforge really. I was really hoping to easily find a link to edit the project so I wouldn't have to search for the addon on other sites. :-/
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Quote from galmok
    Not yet. :-/ But the place will be on curse.com:

    http://wow.curse.com/downloads/wow-addons/details/libcompress.aspx


    I can't navigate curse.com to find the place to edit the page. This will have to wait until it becomes obvious. Until then, use this thread or ask questions at curse.com.
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Not yet. :-/ But the place will be on curse.com:

    http://wow.curse.com/downloads/wow-addons/details/libcompress.aspx
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    16/32 bit FCS checksum/hash algorithm has been added and r36 is tagged as release.
    Posted in: Libraries
  • 0

    posted a message on LibCompress
    Quote from galmok
    My optimised version of the huffman compressor/decompressor had two bugs. Both are fixed in the r32-release of LibCompress.

    Future plans for LibCompress include:

    - Encode/Decode (with optional list of reserved characters and quote-bytes). This will provide the possibility to encode for any channel with any number of reserved bytes.
    Possible syntax:

    codec = LibCompress:GetEncoder(reservedchars, quotebytes)

    encodedData = codec:Encode(compressedData)

    compressedData = codec:Decode(encodedData)

    The reservedchars contains a string with characters that may not occur in th encoded data. Quotebytes contains the characters(s) necessary to perform the encoding. OF course, the bytes in quotebytes may not appear in reservedchars.

    This has been added (not tagged as release yet).

        table, msg = LibCompress:GetEncodeTable(reservedChars, escapeChars,  mapChars)
    reservedChars: The characters in this string will not appear in the encoded data.
    escapeChars: A string of characters used as escape-characters (don't supply more than needed). #escapeChars >= 1
    mapChars: First characters in reservedChars maps to first characters in mapChars. (#mapChars <= #reservedChars)
    return value:
    table
    if nil then msg holds an error message, otherwise use like this:
                encoded_message = table:Encode(message)
                message = table:Decode(encoded_message)


    - Encode/Decode to/from 7-bit characters to 8-bit bytes. This is motivated by the fact that encoding raw huffman data for the chat channel will make the size increase a lot, neglecting any compressing gained with huffman. Reducing from 8 bit to 7 bit will only cause a slight increase in size, requiring much less encoding. Huffman compression will still save bandwidth in this case.

    Suggestion API:
    Encoding:
    sevenbitencoded = LibCompress:Encode7bit(rawdata)

    Decoding:
    rawdata = LibCompress:Decode7bit(sevenbitencoded)

    This could have been built into huffman compression/decompression with 0 speed penalty, but LibCompress has to offer this for all compressors/decompressors which is why I think a separate function should be offered.

    This has also been added and works as described in the quote.

    - Support for predefined symbol statistics for the huffman compressor. For short strings to be compressed, the symbol map is a large part of the compressed data and can neglect any compression gained. Even suboptimal symbol map statistics could provide a gain in compression. This change will not be backwards compatible though.

    This is on the to-do list still.
    Posted in: Libraries
  • 0

    posted a message on strsplit problem
    Both addon and chat channel is used for transmission. Neither of them support \000.

    But having the encoding as the last step in the protocol is more clean and efficient (even when using ssplit instead of strsplit).
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    Quote from OrionShock
    just wondering what are you doing that you end up with a \000 in the string? IIRC \000 is like a tabo thing and isn't used anywhere i know of that would involve anthing guildAds covers...


    \000 isn't tabo for Lua as such. But \000 isn't well supported in Blizzard's API (including strsplit).

    Regarding GuildAds, I am including LibCompress which can result in \000 in the datastream.
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    Hmm yes, this could work, but it would create more string trash than the function.

    Anyway, strsplit is a Blizzard "invention"... They didn't put much thought into it...
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    Quote from Allara
    Would an encode/decode to remove \000 bring the speed at least closer, then?


    If there are no \000 in the data, strsplit is the obvious choice.

    Encoding \000, while efficient, is not always the best solution. For instance, in GuildAds I do encode \000, but only just before sending the data to the channel. Moving that encoding up in the protocol layers would require many changes throughout the code. I _really_ prefer not to mess around with that part right now. ;-)
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    Quote from Xinhuan
    It also creates a ton of table and string garbage. Like a huge ton.


    It doesn't create any other strings that strsplit would create.

    And yes, as it is shown here, it creates 1 table for each call, but that table can be reused easily:

    ocal string_find = string.find
    local string_sub = string.sub
    local table_insert = table.insert
    local unpack = unpack
    local outResults = {}
    local function ssplit( inSplitPattern, str)
        for k in pairs(outResults) do
            outResults[k] = nil
        end
        local theStart = 1
        local theSplitStart, theSplitEnd = string_find( str, inSplitPattern, theStart )
        while theSplitStart do
            table_insert( outResults, string_sub( str, theStart, theSplitStart-1 ) )
            theStart = theSplitEnd + 1
            theSplitStart, theSplitEnd = string_find( str, inSplitPattern, theStart )
        end
        table_insert( outResults, string_sub( str, theStart ) )
        return unpack(outResults)
    end


    Reusing the table like this increases speed and keep memory fragmentation down. Ratio is about 18:1 now. Small improvement. :-)

    If the unpack in the return statement can be remove, the ratio drops to 15:1. This is not really bad, depending on how many calls per second is required (I call it at most 8 times so it is no real issue).
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    I found this code:

    local string_find = string.find
    local string_sub = string.sub
    local table_insert = table.insert
    local unpack = unpack
    local function ssplit( inSplitPattern, str)
        outResults = { }
        local theStart = 1
        local theSplitStart, theSplitEnd = string_find( str, inSplitPattern, theStart )
        while theSplitStart do
            table_insert( outResults, string_sub( str, theStart, theSplitStart-1 ) )
            theStart = theSplitEnd + 1
            theSplitStart, theSplitEnd = string_find( str, inSplitPattern, theStart )
        end
        table_insert( outResults, string_sub( str, theStart ) )
        return unpack(outResults)
    end


    It does exactly what I want. :-)

    Unfortunately, it is 25 times slower than strsplit. :-/
    Posted in: Lua Code Discussion
  • 0

    posted a message on strsplit problem
    I _want_ 3 strings, but mystrsplit function only returns 2... I am looking for an alternative
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.