nseslo ---> lesson (='.'=)

[Mariasole]

R

Oooo, sorry to hear your system released the 'magic smoke', but glad to hear all else worked out for you

Really the "magic smoke"!
You should have seen the smoke coming out of my ears!
Grazie Bogs, sei un tesoro!

(='.'=)

[Mariasole]

Dear friends,
peace and love to all!

I'm trying to learn how the stack works (now that it works on Windows!).

I studied and practically understood everything (I'm optimistic!).

To learn I created another stack and I wrote the scripts step by step, trying not to copy, but to train me to write it "in my words".

Now I've come to a problem that I can not solve.

How can I "import it" in my stack, the "custom properties" that exists on the original stack (uAllWords)?
I tried to copy and paste in the new stack (and in a properties with, naturally, the same name) the "strange" characters I see in the window (Property Contents), but it does not work.

LiveCode tells me:

"
Type decompress: error during decompression
Object card id 1002
Line put decompress(the uAllWords of this stack) into tWords
Hint preOpenCard
"
I have the list that Klaus had kindly made available ...post ago... But I do not understand how to insert it (import it? / import it with compression ???) inside this property!

Sorry for my stupidity , but I just can not do it.
And then, in the end, after two weeks of of tests I humbly ask for help!

=^..^=
Mariasole

[FourthWorld]

It appears the data in the custom prop was not compressed with a standard gzip algo. Where did it come from? Can we examine it to check that?

[SparkOut]

Cara Maria
If you have an updated stack with the original word list that now works on Windows you can open both that stack and your new test stack in the IDE at the same time. Then just

Code: Select all

set the uAllWords of stack "newTest" to the uAllWords of stack "workingWindowsSampleStack"

[bogs]

Another possible suggestion might be to export the custom property from the now working original to a text file, then open your version of the app and import it back in to a custom property.

It appears the data in the custom prop was not compressed with a standard gzip algo. Where did it come from? Can we examine it to check that?

That answer is a few posts back, Elanor answered it after I left a comment on the lesson page.

[FourthWorld]

It appears the data in the custom prop was not compressed with a standard gzip algo. Where did it come from? Can we examine it to check that?

That answer is a few posts back, Elanor answered it after I left a comment on the lesson page.

Thanks. Hunch correct, original data already fixed. Good outcomes.

[Mariasole]

Thank you all for your help!

Thanks caro SparkOut, your line of code works!

But I would like to understand how this import / export works that said Bogs (grazie Bogs!).
Where is the import / export button / menu? How can I do it?

Manually, that is, selecting the whole "Property Contents" field, and then copying it to the same field as the new app, does not work (also copying on a txt and then copying it on the new field).

And then I wonder. How did Elanor "put the compressed data" into the custom property for the first time?

Did Elanor use the "import" button in the "Property Contents" field? But where is this button?

Thanks for the help, I know it's a stupid thing, but I just can not understand!

Thank you all!

=^..^=
Mariasole

[Klaus]

Buongiorno Maria,

Do like this:

Code: Select all

on mouseup
  answer file "Cara Maria, please select the uncompressed text file with all your custom words:"
  if it = EMPTY then
   exit mouseup
  end if

  ## Now import...
  put url("file:" & it) into tWords
  
  ## ...and compress the file...
  put compress(tWords) into tWordsCompressed
  
  ## ...into a custom property:
  set the uAllWords of this stack to tWordsCompressed
end mouseup

Best

Klaus

[bogs]

But I would like to understand how this import / export works that said Bogs (grazie Bogs!).
Where is the import / export button / menu? How can I do it?

Erm, um, ah,....

I am sorry Mariasole, I think I failed to communicate my thoughts properly. There is no import / export button, I was thinking more along the lines of changing the now working programs code, like so -

Code: Select all

on preOpenCard
  -- Fetch the compressed list of words and decompress it
  local tWords
  put decompress(the uAllWords of this stack) into url "file:/tWords.text" --tWords
  // in the line above, after your list of words is exported, remove {url "file:/tWords.text" -- } 
  from before tWords so that the program runs normally again...

which would give you just a basic, uncorrupted text file of all the words in that custom property, like this ~

tWords text file...

You could 'import' it into your version of the program the same exact way in reverse by reading the file into the custom property, or reading the file in compressed (as ali did). Unless I need to save space though, I rarely compress just because of the kinds of issues that crop up (like these).

*Edit - keep in mind my addition will put the 'tWords.text' file into your defaultFolder, unless you put the url somewhere more definitive, like your desktop

[capellan]

Hi All,

Today, this forum thread appeared among the new post list
and just for curiosity, I followed the instructions:

1) Download the stack from lesson webpage
http://lessons.livecode.com/m/4071/l/18 ... finder-app

2) Opened the stack in LiveCode and wrote this code
in the message box:

Code: Select all

put decompress(the uAllWords of this stack)

3) The message box shows a really long list of words that ends
in words like: zythum zythums zyzzyva zyzzyvas zzz zzzs

4) I copied the words list and pasted in a text file.
The size of this text file is 2,974,763 bytes.
The size of this text file compressed as zip is 699,916 bytes

But there is a question that jumped on me as soon
I read the first post: Why we are not requiring that developers
post the MD5, SHA1 or SHA256 of problematic files downloaded
from the web?

For example, the stack Word_Finder.livecode produces
the following Digests:

MD5: 58636526F8AF6C1AD6B995203A69EDD2

SHA1: 4A466651E7CC64946F4B342E9743B90435451C55

SHA256: E32D61A1FE21BD60DD3FBAC71CA0F1FF1B011BD8715695E68DFB72F2B7537D55

SHA512: 2F277F1895DC05EA92588BE3FBD29E300B3802F56FA47481FC08E5AAE0AD953466086D4E4D62B5A7D616AC5FD6B0CCDF18EFCDB701E74D2D8914FC39EE5D3FCC

I am sure that there is a LiveCode stack that produces these Digest
within the LiveCode IDE or for general use, download this Raymond Lin's
utility program from:
https://download.cnet.com/MD5-SHA-Check ... 11445.html

Al

[FourthWorld]

But there is a question that jumped on me as soon
I read the first post: Why we are not requiring that developers
post the MD5, SHA1 or SHA256 of problematic files downloaded
from the web?

Probably because we don't know a file is problematic until someone trying to use it lets us know.

This was a very odd edge case, in which someone at LC Ltd had made the stack using a data file pre-compressed with what was reported to be standard gzip. Whatever it was it worked on their machine, so they uploaded it and never thought about it again.

It wasn't until all these months (years?) later that someone notice the data is corrupt on some platforms. Odd for anything gzip to do that, but I'm no gzip expert.

Anyway, as I understand it the team has confirmed the issue, re-uploaded the stack with uncorrupted data, and the issue is resolved.

So even if they were in the habit of using a hash to validate that what they uploaded is what we downloaded, that wouldn't have identified the problem here since this wasn't a problem with the stack being altered on the server, but with the original stack file containing erroneous data.

[bogs]

Al does mention another way of achieving Mariasole's objective (thanks Al! ) that I forgot to mention, using the message box after the stack is open to just put the tWords into a text file that she can use in her version.

@Al ~ The file itself wasn't corrupt, there was actually nothing at all wrong with the file or the compressed information, which is why people using Mac OS had no issue running the program. The problem was that the compression routine used was
..a.) not Lc's built in version, and
..b.) not a format widely used on other OSs, like .zip.

If I had to lay money on it, I would guess that they used the archive utilities cpgz functionality, again because it presented no problem on the Mac systems.

In this case, as Richard points out, providing a hash of any kind would not indicate an issue.

Aside from that though ~

Why we are not requiring that developers
post the MD5, SHA1 or SHA256 of problematic files downloaded
from the web?

How would you require it? Only if your posting to the lessons page? Posting in the forums? Posting anywhere you might post a demo stack?

Better question, how would it be enforced? Explained? Introduced?

Posting that information is fine if the dev chooses too, and is a good idea in general to make sure of your (end user) getting what you intend to. I just don't see how your going to 'require' someone to do something they may (or may not) want or even know how to do.

[Mariasole]

Grazie infinite Klaus e Bogs!
Thank you all for the availability! I see that my ignorance has allowed us to discover problems! I'm happy!
Now I understand how to "import / export" (I put it in quotes), the file compressed (or compressed!) Inside a custom property.
And I can continue my experiments! As for MD5, SHA1 or SHA256 I still do not understand what they are for!
But one day, when I become good (between 4, 5, 6 decades!) I can also participate in the discussion!

Thank you so much to everyone, siete dei tesori!

=^..^=
Mariasole

[bogs]

As for MD5, SHA1 or SHA256 I still do not understand what they are for!
But one day, when I become good (between 4, 5, 6 decades!) I can also participate in the discussion!

I think your alright now, so you shouldn't wait nearly so long

Here is a pretty good breakdown of hash algorithms and what they are for.

Al's point was for the use of the hash process along these lines ~

Verifying the integrity of messages and files
Main article: File verification

An important application of secure hashes is verification of message integrity. Comparing message digests (hash digests over the message) calculated before, and after, transmission can determine whether any changes have been made to the message or file.

MD5, SHA1, or SHA2 hash digests are sometimes published on websites or forums to allow verification of integrity for downloaded files, including files retrieved using file sharing such as mirroring. This practice establishes a chain of trust so long as the hashes are posted on a site authenticated by HTTPS. Using a cryptographic hash and a chain of trust prevents malicious changes to the file to go undetected. Other error detecting codes such as cyclic redundancy checks only prevent against non-malicious alterations of the file.

*Edit - I should have mentioned they are pretty easy to generate as well for internal parts of your application. Max's Wiki has a pretty good breakdown on the topic

[capellan]

Hash algorithms check files integrity. Comparing Images and sounds
requires other algorithms:
http://www.imagemagick.org/Usage/compare/#compare
https://forums.ni.com/t5/LabVIEW/Compar ... d-p/281203

Al