Re: cross-platform compress decompress
On Tuesday, December 2, 2003, at 04:55 PM, Wouter wrote: ## result = -1448432724 2846534572 2846534572 294 664 Wow, you have a nice rig :) Mac X, G3 900 MHz, iBook, 14 screen. It keeps up with my IBM XP laptop 2.1 GHz That was tricky using a string of comma delimited numbers to then use repeat with each item X in groovyString for looping. This added extra speed everywhere I tested it. check this out from below: put halfblock1 halfblock2 halfblock3 t1 t2 t3 t4 ## result = -1448432724 2846534572 2846534572 668 714 1011 607 ## second = -1448432724 2846534572 2846534572 667 871 1034 607 this is faster: put binaryDecode(I,x,halfBlock2) into numConverted this is slower: put charToNum(char 4 of x) + (charToNum(char 3 of x) * 256) + (charToNum(char 2 of x) * 65536) + (charToNum(char 1 of x) * 16777216) bitAnd 4294967295 into halfBlock3 = this is faster: put ((xL bitAnd 4278190080) / 16777216) into zp put (zp bitAnd 255) into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d this is slower: put binaryDecode(,binaryEncode(I,xL),a,b,c,d) into numConverted on mouseUp ## I added speed testing put num2char(169,170,171,172) into x ## N - decode signed four-byte integers in network order ## put binaryDecode(N,x,halfBlock1) into numConverted ## I - decode unsigned four-byte integers in host order put the milliseconds into zap1 repeat with i = 1 to 10 put binaryDecode(I,x,halfBlock2) into numConverted end repeat put the milliseconds into zap2 put zap2 - zap1 into t1 ## my current solution put the milliseconds into zap6 repeat with ii = 1 to 10 put charToNum(char 4 of x) + (charToNum(char 3 of x) * 256) + (charToNum(char 2 of x) * 65536) + (charToNum(char 1 of x) * 16777216) bitAnd 4294967295 into halfBlock3 end repeat put the milliseconds into zap7 put zap7 - zap6 into t2 put halfBlock2 into xL put the milliseconds into zap3 repeat with ii = 1 to 10 put binaryDecode(,binaryEncode(I,xL),a,b,c,d) into numConverted --put binaryEncode(N,xL) into fourChars --put binaryDecode(,fourChars,a,b,c,d) into numConverted end repeat put the milliseconds into zap4 put zap4 - zap3 into t3 put the milliseconds into zap5 repeat with ii = 1 to 10 put ((xL bitAnd 4278190080) / 16777216) into zp put (zp bitAnd 255) into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d end repeat put the milliseconds into zap6 put zap6 - zap5 into t4 put halfblock1 halfblock2 halfblock3 t1 t2 t3 t4 ## result = -1448432724 2846534572 2846534572 668 714 1011 607 ## second = -1448432724 2846534572 2846534572 667 871 1034 607 end mouseUp function num2char sx repeat for each item i in sx put numtochar(i) after z end repeat return z end num2char Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On 03 Dec 2003, at 16:43, [EMAIL PROTECTED] wrote: Message: 1 Date: Wed, 3 Dec 2003 00:04:14 -0800 From: Mark Brownell [EMAIL PROTECTED] Subject: Re: cross-platform compress decompress To: How to use Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed snip Mark You're really on to the fast track :^) Hope to see your results soon. Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On 03 Dec 2003, at 16:43, [EMAIL PROTECTED] wrote: Message: 1 Date: Wed, 3 Dec 2003 00:04:14 -0800 From: Mark Brownell [EMAIL PROTECTED] Subject: Re: cross-platform compress decompress To: How to use Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed snip this is faster: put ((xL bitAnd 4278190080) / 16777216) into zp put (zp bitAnd 255) into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d this is slower: put binaryDecode(,binaryEncode(I,xL),a,b,c,d) into numConverted but this is still a bit faster: put ((xL bitAnd 4278190080) / 16777216) bitAnd 255 into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d Mark on mouseUp ## I added speed testing put num2char(169,170,171,172) into x ## N - decode signed four-byte integers in network order ## put binaryDecode(N,x,halfBlock1) into numConverted ## I - decode unsigned four-byte integers in host order put binaryDecode(I,x,halfBlock2) into numConverted put halfBlock2 into xL put the milliseconds into zap1 repeat with ii = 1 to 10 put ((xL bitAnd 4278190080) / 16777216) into zp put (zp bitAnd 255) into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d end repeat put the milliseconds into zap2 put zap2 - zap1 into t1 put the milliseconds into zap3 repeat with ii = 1 to 10 put ((xL bitAnd 4278190080) / 16777216) bitAnd 255 into a put ((xL bitAnd 16711680) / 65536) into b put ((xL bitAnd 65280) / 256) into c put (xL bitAnd 255) into d end repeat put the milliseconds into zap4 put zap4 - zap3 into t2 put halfblock2 t1 t2 ## result = 2846534572 1406 1120 ## second = 2846534572 1424 1115 /* yep my rig is slower :^) 400 mhz g4 Tibook */ end mouseUp function num2char sx repeat for each item i in sx put numtochar(i) after z end repeat return z end num2char It is getting under the skin. Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Wednesday, December 3, 2003, at 02:58 PM, Wouter wrote: You're really on to the fast track :^) Hope to see your results soon. Greetings, WA What you are looking at is the old ECB (electronic code book) version. I added my own version of CBC (Cypher Block Chaining) to make it even more difficult to decrypt. I have it broken down into three parts now. The S1, S2, S3, S4, Sp boxes are created and stored in globals so that encrypt decrypt can run faster without having to re-initialize the boxes before using them. These boxes could be called from internally saved property arrays for use with a pre-fixed encryption key. This allows for different initialization vectors for CBC for each call. Isn't that fun? mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Wednesday, December 3, 2003, at 03:48 PM, Wouter wrote: ## result = 2846534572 1406 1120 ## second = 2846534572 1424 1115 /* yep my rig is slower :^) 400 mhz g4 Tibook */ It is getting under the skin. Greetings, WA Those are impressive numbers just for combining two lines. I wonder if I go back and combine more lines if I can squeeze a little more out of it? 2846534572 606 556 -- G3; 900 MHz I was on a Mac 210 MHz for six years until this last summer when I got the G3. Now I'm drooling over the Mac G5s. It never changes... the grass is always greener... mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On 02 Dec 2003, at 03:38, [EMAIL PROTECTED] wrote: Message: 4 Date: Mon, 1 Dec 2003 16:36:59 -0800 From: Mark Brownell [EMAIL PROTECTED] Subject: Re: cross-platform compress decompress To: How to use Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed snip I have tried compressing and decompressing the whole file as the first test. I tried compressing the data from a variable as a second test. I've looked at the same data in a text editor on both platforms and I did a comparison of charToNum() of the compressed data on both platforms. This was the exact same problem I had with blowfish I think. I solved it by constricting cross-platform data transfers to less than ascii 127; even though the data can represent up to ascii 255. My blowfish algorithm does it all as numerical values until the final rendering. I had to drop binaryEncode() binaryDecode() in order to get numerical only results within the process. That's why I think it's something like upper ascii character values across platforms. The put binaryDecode(N,str,halfBlock) into numConverted in your blowfish handler can produce an unsigned integer on the Windows platform where as on the Mac a signed integer is produced. This is probably an engine related problem. To test this try the following on both platforms and compare: on mouseUp put num2char(169,170,171,172) into x ## N - decode signed four-byte integers in network order put binaryDecode(N,x,halfBlock1) into numConverted ## I - decode unsigned four-byte integers in host order put binaryDecode(I,x,halfBlock2) into numConverted put halfblock1 halfblock2 end mouseUp function num2char sx repeat for each item i in sx put numtochar(i) after z end repeat return z end num2char Greetings, WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Tuesday, December 2, 2003, at 04:48 AM, Wouter wrote: The put binaryDecode(N,str,halfBlock) into numConverted in your blowfish handler can produce an unsigned integer on the Windows platform where as on the Mac a signed integer is produced. This is probably an engine related problem. To test this try the following on both platforms and compare [snip] Greetings, WA PS In fact with a litle adjustment your Blowfish stack is working on both platforms I tried it with a speed test and the solution I'm using now: on mouseUp ## I added speed testing put num2char(169,170,171,172) into x ## N - decode signed four-byte integers in network order put binaryDecode(N,x,halfBlock1) into numConverted ## I - decode unsigned four-byte integers in host order put the milliseconds into zap1 repeat with i = 1 to 10 put binaryDecode(I,x,halfBlock2) into numConverted end repeat put the milliseconds into zap2 put zap2 - zap1 into t1 ## my solution I'm using now put the milliseconds into zap6 repeat with ii = 1 to 10 put charToNum(char 4 of x) + (charToNum(char 3 of x) * 256) + (charToNum(char 2 of x) * 65536) + (charToNum(char 1 of x) * 16777216) bitAnd 4294967295 into halfBlock3 end repeat put the milliseconds into zap7 put zap7 - zap6 into t2 put halfblock1 halfblock2 halfblock3 t1 t2 ## result = -1448432724 2846534572 2846534572 294 664 end mouseUp function num2char sx repeat for each item i in sx put numtochar(i) after z end repeat return z end num2char I'll have to see if this works with macToIso/isoToMac for delivery. I'm curently using ascii numbers that in the end take the charSet issue out of the delivery issue for decryption. The numbers also split out into an array that allows for one step to be dropped during decryption. Thank you for mentioning this. This could add at the least a 100% increase in speed to the current state of the working version. Mark Brownell ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On 02 Dec 2003, at 18:00, [EMAIL PROTECTED] wrote: Message: 1 Date: Tue, 2 Dec 2003 07:48:17 -0800 From: Mark Brownell [EMAIL PROTECTED] Subject: Re: cross-platform compress decompress To: How to use Revolution [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed snip ## result = -1448432724 2846534572 2846534572 294 664 Wow, you have a nice rig :^) Mark Brownell WA ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Dec 1, 2003, at 4:19 PM, Mark Brownell wrote: I've read everything I can find in the archives and I'm wondering if anyone has solved the cross-platform compress decompress problems. I would like to create a compressed text file on Mac X and open decompress it on Windows, the same goes for make on Windows open on Mac. I'm not sure but it looks like the different charSets for each OS seems to be the problem. Anyway when I try to open made on Mac in Windows the file is not recognized as being compressed. I've tried stripping the header before decompressing with no luck. Perhaps a cross-platform compress/decompress is in the works soon? I solved these charSet OS issues in cross-platform encryption by converting to numbers within the entire encryption/decryption process. This took the relative positions of the different chars in charSets out of picture until the final rendering takes place. Would base64 encoding the content before compressing it be a suitable workaround for the char set issues? Is there a bugzilla # I can read to get up to speed on this bug? Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
Mark Brownell wrote: I've read everything I can find in the archives and I'm wondering if anyone has solved the cross-platform compress decompress problems. I've been using base64 on the compressed data to maintain it unadulterated in user props or for transmission. It adds some bulk, but the net result is still usually much smaller than the original. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
Alex Rice wrote: On Dec 1, 2003, at 4:19 PM, Mark Brownell wrote: I've read everything I can find in the archives and I'm wondering if anyone has solved the cross-platform compress decompress problems. I would like to create a compressed text file on Mac X and open decompress it on Windows, the same goes for make on Windows open on Mac. I'm not sure but it looks like the different charSets for each OS seems to be the problem. Anyway when I try to open made on Mac in Windows the file is not recognized as being compressed. I've tried stripping the header before decompressing with no luck. Perhaps a cross-platform compress/decompress is in the works soon? I solved these charSet OS issues in cross-platform encryption by converting to numbers within the entire encryption/decryption process. This took the relative positions of the different chars in charSets out of picture until the final rendering takes place. Would base64 encoding the content before compressing it be a suitable workaround for the char set issues? Is there a bugzilla # I can read to get up to speed on this bug? I don't think it's a bug as much as a very useful feature with unintended consequences for binary data: in old versions of the engine, folks complained that data stored in user properties did not have the automatic cross-platform conversion as text in fields enjoy. So several versions ago this was changed to allow the same for user props. The downside to the change is that for the minority of user props containing binary data this conversion will cause trouble, often making the data unusable (as is the case if the data is compressed). Maybe we need a flag to note whether a property is text or binary? Should it be a stack property? -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Dec 1, 2003, at 4:27 PM, Richard Gaskin wrote: I don't think it's a bug as much as a very useful feature with unintended consequences for binary data: in old versions of the engine, folks complained that data stored in user properties did not have the automatic cross-platform conversion as text in fields enjoy. So several versions ago this was changed to allow the same for user props. The downside to the change is that for the minority of user props containing binary data this conversion will cause trouble, often making the data unusable (as is the case if the data is compressed). When did that happen? I thought that custom properties are a place where binary data was really safe in Rev. In either case I misunderstood Mark's question. I thought he meant compressing data X on two different platforms would yield 2 different chunks of binary data. Maybe we need a flag to note whether a property is text or binary? Should it be a stack property? Just as a transcript notation you mean? Sounds useful Alex Rice [EMAIL PROTECTED] | Mindlube Software | http://mindlube.com what a waste of thumbs that are opposable to make machines that are disposable -Ani DiFranco ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Monday, December 1, 2003, at 03:19 PM, Alex Rice wrote: Would base64 encoding the content before compressing it be a suitable workaround for the char set issues? Base64 would not help. It's not before compression that is the issue. The stuff I'm encrypting already has a less-than 127 numToChar() value restriction. If you look at the text of the compressed data you will see many ascii characters that numToChar() higher than 127. These chars read differently on different Systems. Even if you macToISO() the chars they end up changing the decompress process on different platforms. Is there a bugzilla # I can read to get up to speed on this bug? I only found one and it said it was resolved. I think this might be a feature request kind of an issue. mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
I have a system that works for me, it's plain text. This example opens on all platforms and is without cross-platform issues: mtml noteBook=version 1.0 mtmlVersion=3.0 authorn/a/author titleDemo Document/title copyrightn/a/copyright publisherwww.demotypeX.com/publisher offSetPage1/offSetPage docSettings 61 173 254 201 112 131 124 144 25 151 90 58 97 202 63 89 92 6 195 93 79 163 159 77 171 228 84 228 [snip]... /docSettings dictionary termDictionary InformationdefinitionNo dictionary information available./definition/term /dictionary indicated termAdd a term later/term /indicated /mtml page 135 157 165 249 203 64 187 98 25 182 92 175 143 130 104 126 204 151 137 247 154 167 240 68 138 168 134 37 0 10 37 131 113 108 191 14 208 46 170 95 105 30 110 123 49 72 24 246 129 148 [snip]... /page The snipped sets of numbers are encrypted data that exists between the tag sets. I was just looking for a way to make it smaller. mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
At 3:27 pm -0800 1/12/03, Richard Gaskin wrote: On Dec 1, 2003, at 4:19 PM, Mark Brownell wrote: I've read everything I can find in the archives and I'm wondering if anyone has solved the cross-platform compress decompress problems. I would like to create a compressed text file on Mac X and open decompress it on Windows, the same goes for make on Windows open on Mac. I'm not sure but it looks like the different charSets for each OS seems to be the problem. Anyway when I try to open made on Mac in Windows the file is not recognized as being compressed. I've tried stripping the header before decompressing with no luck. Perhaps a cross-platform compress/decompress is in the works soon? I solved these charSet OS issues in cross-platform encryption by converting to numbers within the entire encryption/decryption process. This took the relative positions of the different chars in charSets out of picture until the final rendering takes place. Are you treating the files as binary data and not as text files? That is, when you save and open, you should use binfile and not file. For example: When saving: put compress(field 1) into url (binfile: someFile) When opening: put decompress(url (binfile: somefile)) into field 1 I don't think it's a bug as much as a very useful feature with unintended consequences for binary data: in old versions of the engine, folks complained that data stored in user properties did not have the automatic cross-platform conversion as text in fields enjoy. So several versions ago this was changed to allow the same for user props. Are you sure that's true, Richard? I use custom props for image data, audio, and a host of other binary data but haven't noticed any cross platform issues. Dave ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Monday, December 1, 2003, at 03:59 PM, Dave Cragg wrote: Are you treating the files as binary data and not as text files? That is, when you save and open, you should use binfile and not file. For example: I'm using binfile for all. This works fine on Win and works fine for Mac as long as I use binary files created on the same platform. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
RE: cross-platform compress decompress
On Monday, December 1, 2003, at 03:59 PM, Dave Cragg wrote: Are you treating the files as binary data and not as text files? That is, when you save and open, you should use binfile and not file. For example: I'm using binfile for all. This works fine on Win and works fine for Mac as long as I use binary files created on the same platform. Try compressing an decompressing the whole file to see if some stage in your parsing is corrupting the compressed data. Richard's suggestion of compress then base64Encode is also appropriate for binary data in an XML document. Cheers Monte ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
At 4:01 pm -0800 1/12/03, Mark Brownell wrote: I have a system that works for me, it's plain text. This example opens on all platforms and is without cross-platform issues: Mark, could you provide an example that doesn't work? I've never encountered this problem, and I open a lot of compressed files (usally stacks) across Win and Mac platforms. Are you using e-mail to transfer the files? I've come across cases of supposedly binary files being converted during e-mail transmission. Cheers Dave ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Monday, December 1, 2003, at 04:15 PM, Monte Goulding wrote: Try compressing an decompressing the whole file to see if some stage in your parsing is corrupting the compressed data. Richard's suggestion of compress then base64Encode is also appropriate for binary data in an XML document. Cheers Monte I have tried compressing and decompressing the whole file as the first test. I tried compressing the data from a variable as a second test. I've looked at the same data in a text editor on both platforms and I did a comparison of charToNum() of the compressed data on both platforms. This was the exact same problem I had with blowfish I think. I solved it by constricting cross-platform data transfers to less than ascii 127; even though the data can represent up to ascii 255. My blowfish algorithm does it all as numerical values until the final rendering. I had to drop binaryEncode() binaryDecode() in order to get numerical only results within the process. That's why I think it's something like upper ascii character values across platforms. So can you compress this: abcdefghijklmnopqrstuvwxyz1234567890 on a Mac, save it as binary on a Mac, and open decompress it on a Windows machine? I need to see a basic text file that I can decompress on Mac Windows. \ mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Monday, December 1, 2003, at 04:17 PM, Dave Cragg wrote: Mark, could you provide an example that doesn't work? I've never encountered this problem, and I open a lot of compressed files (usally stacks) across Win and Mac platforms. Are you using e-mail to transfer the files? I've come across cases of supposedly binary files being converted during e-mail transmission. I'm zipping the Mac files and then FTPing them to my website. I'm then downloading them, unzipping them on Windows. After that I can open the text files but I can't use Rev to decompress the Mac .gz files. Windows recognizes these compressed files as .gz but won't let me decompress them. \ mb ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
Mark Brownell wrote: On Monday, December 1, 2003, at 04:17 PM, Dave Cragg wrote: Mark, could you provide an example that doesn't work? I've never encountered this problem, and I open a lot of compressed files (usally stacks) across Win and Mac platforms. Are you using e-mail to transfer the files? I've come across cases of supposedly binary files being converted during e-mail transmission. I'm zipping the Mac files and then FTPing them to my website. I'm then downloading them, unzipping them on Windows. After that I can open the text files but I can't use Rev to decompress the Mac .gz files. Windows recognizes these compressed files as .gz but won't let me decompress them. \ mb There may be something else in the mix: RevNet has a lot of gzipped files from both platforms and this has not been reported as a problem there. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge: Publish any database on any Web site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
Dave Cragg wrote: I don't think it's a bug as much as a very useful feature with unintended consequences for binary data: in old versions of the engine, folks complained that data stored in user properties did not have the automatic cross-platform conversion as text in fields enjoy. So several versions ago this was changed to allow the same for user props. Are you sure that's true, Richard? I use custom props for image data, audio, and a host of other binary data but haven't noticed any cross platform issues. I may be getting old and feeble, recalling merely a discussion of what would happen if the request were implemented. I can't recall a specific instance of custom props failing with binary data for me, so chalk that up to a lack of sleep until someone confirms/denies it empirically. However, i used to have issues sending compressed data over sockets until I got into the habit of using base64. But since I've never had a problem using your excellent libUrl even those may have been user error. :) I started using base64 early on in my works with sockets, so other factors may have been at play while I was getting the hang of it. But the issue seems bigger than Mark and myself: I recall a number of cases where using compress/decompress across platforms was discussed here as problematic, though I don't recall if storing them in user props or transmitting via sockets was a consistent part of the recipe. -- Richard Gaskin Fourth World Media Corporation ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On Monday, December 1, 2003, at 05:01 PM, Richard Gaskin wrote: There may be something else in the mix: RevNet has a lot of gzipped files from both platforms and this has not been reported as a problem there. I'm using this on a Mac X: put abcdefghijklmnopqrstuvwxyz1234567890 into tankX ask file Save: with Untitled.txt put compress(tankX) into URL (binfile: it .gz) I get this: KLJNIMK/(,*.)-+24261534 d It will be fun to compare what comes through the list as ascii chars for the result... So I put this file on-line zipped and... Wouldn't you know it, it works fine! I used this on the Windows machine: answer file this put decompress(URL (binfile: it )) into zap put zap -- returns abcdefghijklmnopqrstuvwxyz1234567890 OK I've discovered a bug with me. I zipped me... It turns out I was sending header data in the first line of the compressed data. Once I dropped that it worked fine. Thanks to all, Mark ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: cross-platform compress decompress
On 12/1/03 7:22 PM, Richard Gaskin wrote: Dave Cragg wrote: Are you sure that's true, Richard? I use custom props for image data, audio, and a host of other binary data but haven't noticed any cross platform issues. I may be getting old and feeble, recalling merely a discussion of what would happen if the request were implemented. I made the same misstatement here six months or so ago, and maybe for the same reason you did. I am sure I remember a note in one of the what's new files in a version of MC a while back which said that line endings in custom props were now converted. I remember being relieved because I had some trouble with that once. Folks here corrected me, and now I don't know whether line conversion worked for a while and then was reverted later on, or whether I just dreamed the whole thing. I can't recall a specific instance of custom props failing with binary data for me, so chalk that up to a lack of sleep until someone confirms/denies it empirically. The reason I brought it up six months ago was because I was storing compressed data in a custom property that would not decompress on a different platform. If I compressed it on Mac it wouldn't decompress on Windows and vice versa. I never did get it to work. I had to create two versions of the compressed data, one for each platform. The data was all just plain ascii text, and I don't think there were any high-ascii characters in it. But the issue seems bigger than Mark and myself: I recall a number of cases where using compress/decompress across platforms was discussed here as problematic, though I don't recall if storing them in user props or transmitting via sockets was a consistent part of the recipe. That was me, for at least one of the times, and it was custom props. I haven't tested it again since then. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
