Discussion:
Most Efficient Timer?
(too old to reply)
Scott Rossi
2004-11-29 08:00:50 UTC
Permalink
I've been thinking about timers recently and thought I run this by the list
to see what other Rev experts thought. I guess the way to set this is up
is: "Can you script a more efficient timer?"

----------

The way I usually build asynchronous timers uses a "send in" structure like
the following: (simplified for example)

local tCurrTime
on runTimer
if not the uAllowTimer of me then exit runTimer
if (the millisecs > tCurrTime + 1000) then
put the millisecs into tCurrTime
put the long time into fld 1
end if
send "runTimer" to me in 100 millisecs
end runTimer

The above example checks the value of the milliseconds 10 times a second and
puts the result into a locked field after one second has elapsed. But it
also generates 10 messages a second, and it occurred to me that another way
to do this is to use the "wait x with messages" construct which I'm guessing
evaluates time many more times a second, but at a lower level than "send
in":

local tCurrTime
on runTimer
repeat forever
if not the uAllowTimer of me then exit runTimer
wait until (the millisecs > tCurrTime + 1000) or \
(not the uAllowTimer of me) with messages
put the millisecs into tCurrTime
put the long time into fld 1
end repeat
end runTimer

Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).

Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.

Obviously the above is useful only in situations requiring accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?

Regards,

Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
E: ***@tactilemedia.com
W: http://www.tactilemedia.com
Richard Gaskin
2004-11-29 09:11:51 UTC
Permalink
Post by Scott Rossi
I've been thinking about timers recently and thought I run this by the list
to see what other Rev experts thought. I guess the way to set this is up
is: "Can you script a more efficient timer?"
----------
The way I usually build asynchronous timers uses a "send in" structure like
the following: (simplified for example)
local tCurrTime
on runTimer
if not the uAllowTimer of me then exit runTimer
if (the millisecs > tCurrTime + 1000) then
put the millisecs into tCurrTime
put the long time into fld 1
end if
send "runTimer" to me in 100 millisecs
end runTimer
The above example checks the value of the milliseconds 10 times a second and
puts the result into a locked field after one second has elapsed. But it
also generates 10 messages a second, and it occurred to me that another way
to do this is to use the "wait x with messages" construct which I'm guessing
evaluates time many more times a second, but at a lower level than "send
local tCurrTime
on runTimer
repeat forever
if not the uAllowTimer of me then exit runTimer
wait until (the millisecs > tCurrTime + 1000) or \
(not the uAllowTimer of me) with messages
put the millisecs into tCurrTime
put the long time into fld 1
end repeat
end runTimer
Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).
Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.
Obviously the above is useful only in situations requiring accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?
None that I can see, but I managed to get myself confused on the issue:
if you only want a time sent once a second, why not just send it in 1
second rather than polling several times a second?

--
Richard Gaskin
Fourth World Media Corporation
__________________________________________________
Rev tools and more: http://www.fourthworld.com/rev
Dave Cragg
2004-11-29 11:29:58 UTC
Permalink
Post by Richard Gaskin
Post by Scott Rossi
Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).
Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.
Obviously the above is useful only in situations requiring accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?
None that I can see, but I managed to get myself confused on the
issue: if you only want a time sent once a second, why not just send
it in 1 second rather than polling several times a second?
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something
holding up message processing, the timer may be late to update.
Increasing the frequency increases the chance of getting it right (but
doesn't guarantee it).

One uncertainty about the "wait <condition> with messages" is that it
isn't documented how frequently the condition is evaluated. I was told
once that "wait ... with messages" was inefficient because it was
constantly evaluating the condition. However, this doesn't seem to be
the case.
Richard Gaskin
2004-11-29 11:56:21 UTC
Permalink
Post by Dave Cragg
Post by Richard Gaskin
Post by Scott Rossi
Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).
Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.
Obviously the above is useful only in situations requiring accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?
None that I can see, but I managed to get myself confused on the
issue: if you only want a time sent once a second, why not just send
it in 1 second rather than polling several times a second?
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something holding
up message processing, the timer may be late to update. Increasing the
frequency increases the chance of getting it right (but doesn't
guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?

--
Richard Gaskin
Fourth World Media Corporation
__________________________________________________
Rev tools and more: http://www.fourthworld.com/rev
Geoff Canyon
2004-11-29 14:47:29 UTC
Permalink
Post by Richard Gaskin
Post by Dave Cragg
Post by Richard Gaskin
Post by Scott Rossi
Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).
Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.
Obviously the above is useful only in situations requiring accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?
None that I can see, but I managed to get myself confused on the
issue: if you only want a time sent once a second, why not just
send it in 1 second rather than polling several times a second?
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something
holding up message processing, the timer may be late to update.
Increasing the frequency increases the chance of getting it right
(but doesn't guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
Anything that's going to stop a 1 second message is also going to stop
a 1/10 second message as well. It's possible I suppose for send...in to
take slightly longer than a second, so when a visible display is
ticking over I generally use something like 55 ticks, which should
(virtually) guarantee that it will tick over.

wait...with messages is perfectly fine to use. The one that hogs the
system is when you wait for a system condition to change: wait until
the mouse is up, repeat while the mouse is down, that sort of thing.
Even then it's okay if you're actually _doing_ something. The problem
enters in when you have something like

repeat while the mouse is "down"
set the loc of me to the mouseLoc
end repeat

The problem here is that as fast as the system is able you're setting
the loc of the object to the exact same value (because most of the time
the mouse isn't moving).

Specifically, there is nothing wrong with wait 55 ticks with messages.

Further, you will still see a responsive system with wait 0 ticks with
messages. In that video game I programmed a year back, I have a delay
loop to keep the game from running too fast on very fast systems. It
keeps track of how long it needs to wait to update the screen. On
slower systems, that value can decrease to 0, or even -1 or -3, so the
code executed is

wait -3 ticks with messages

It still works.

regards,

Geoff Canyon
***@inspiredlogic.com
Dave Cragg
2004-11-29 16:03:26 UTC
Permalink
Post by Geoff Canyon
Post by Richard Gaskin
Post by Dave Cragg
Post by Richard Gaskin
Post by Scott Rossi
Both of the above routines provide the same output. However, when viewing
the %CPU use on a Mac OSX system with the Activity Monitor, CPU usage is
clearly dependent on the frequency of the "send in" message: with 100
milliseconds frequency, the first handler runs at about 15% usage, and with
50 milliseconds frequency runs at about 30% usage (makes sense).
Amazingly, the "wait x with messages" handler runs at less than 1% usage.
And because "with messages" does not block other messages from being sent,
this seems a very efficient way to run a timer.
Obviously the above is useful only in situations requiring
accuracy of 1
second or less, but at first glance I can't see any drawback to using this
method. Can you?
None that I can see, but I managed to get myself confused on the
issue: if you only want a time sent once a second, why not just
send it in 1 second rather than polling several times a second?
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something
holding up message processing, the timer may be late to update.
Increasing the frequency increases the chance of getting it right
(but doesn't guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
Anything that's going to stop a 1 second message is also going to stop
a 1/10 second message as well. It's possible I suppose for send...in
to take slightly longer than a second, so when a visible display is
ticking over I generally use something like 55 ticks, which should
(virtually) guarantee that it will tick over.
My brain's hurting thinking about this. But if you send in 55 ticks,
there's a good chance you won't have hit the next second when the
message is handled, and so the timer display won't update until the
next time through. So you're likely to get a visibly uneven update.

If you send in 1 second, it's probably going a fraction more than I
second between the "send" and the point where the display is updated.
Eventually, you're going to see a 2 second jump in the display.
Post by Geoff Canyon
wait...with messages is perfectly fine to use. The one that hogs the
system is when you wait for a system condition to change: wait until
the mouse is up, repeat while the mouse is down, that sort of thing.
Even then it's okay if you're actually _doing_ something. The problem
enters in when you have something like
The "repeat until the mouse is down" problem I can understand. But I
need more convincing about "wait".

wait until (x + y > 1000) with messages -- assume x & y are script
locals or globals
wait until the mouse is up with messages
wait until myFunction() with messages -- assume myFunction returns
true or false

Won't the frequency at which the conditional is evaluated be the same?
If it gets evaluated as soon as nothing else is happening, then you'd
expect all three to be processor intensive. But it doesn't seem to
happen that way. On the other hand, I can't see what determines the
frequency either.

Cheers
Dave
Scott Rossi
2004-11-29 16:58:02 UTC
Permalink
Post by Richard Gaskin
Post by Dave Cragg
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something holding
up message processing, the timer may be late to update. Increasing the
frequency increases the chance of getting it right (but doesn't
guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
It could, but if one is after one second accuracy, for example, the
one-second timer will be thrown off, whereas the 1/10-second timer has the
opportunity to correct itself (assuming whatever issues delay the timer
don't take 3 seconds to execute).

Regards,

Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
E: ***@tactilemedia.com
W: http://www.tactilemedia.com
Richard Gaskin
2004-11-29 17:39:39 UTC
Permalink
Post by Scott Rossi
Post by Richard Gaskin
Post by Dave Cragg
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something holding
up message processing, the timer may be late to update. Increasing the
frequency increases the chance of getting it right (but doesn't
guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
It could, but if one is after one second accuracy, for example, the
one-second timer will be thrown off, whereas the 1/10-second timer has the
opportunity to correct itself (assuming whatever issues delay the timer
don't take 3 seconds to execute).
If a message were completely removed from the queue that would be an
issue. But if the message is merely delayed until the next idle,
wouldn't all messages that are due for firing get fired in their firing
order, regardless of the wait period specified when they were queued?
--
Richard Gaskin
Fourth World Media Corporation
Developer of WebMerge: Publish any database on any Web site
___________________________________________________________
***@FourthWorld.com http://www.FourthWorld.com
Steve Bonham
2004-11-29 18:57:09 UTC
Permalink
Hi Revolutionaries,

I'm lost regarding the encrypt and decrypt commands.

I've created a Jeopardy-like game and saved it as a stand-alone application.

When the user closes the stack their preferences (number of daily
doubles, row values, default game file, user password, etc) are
written to an external text file.

When the user opens the stack the last used preferences are read and
loaded into flds or variables to re-configure the game as it was last
used.

AhHa! You see the problem already... Anyone can open the settings.txt
file and see the password!

I'd like to encrypt the password on closestack and write that to the
file. Then import and decrypt the password. But I don't understand
the Rev documentation for encrypt & decrypt. The following makes NO
sense to me at all...

encrypt source using cipher with [password|key] passorkey[and salt
saltvalue] [and IV IVvalue] [at bit ]

Can someone provide some sample Transcript that will enlighten me?

Thx,
Steve
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Mark Talluto
2004-11-29 19:02:52 UTC
Permalink
Post by Steve Bonham
Hi Revolutionaries,
I'm lost regarding the encrypt and decrypt commands.
I've created a Jeopardy-like game and saved it as a stand-alone application.
When the user closes the stack their preferences (number of daily
doubles, row values, default game file, user password, etc) are
written to an external text file.
When the user opens the stack the last used preferences are read and
loaded into flds or variables to re-configure the game as it was last
used.
AhHa! You see the problem already... Anyone can open the settings.txt
file and see the password!
I'd like to encrypt the password on closestack and write that to the
file. Then import and decrypt the password. But I don't understand the
Rev documentation for encrypt & decrypt. The following makes NO sense
to me at all...
encrypt source using cipher with [password|key] passorkey[and salt
saltvalue] [and IV IVvalue] [at bit ]
Can someone provide some sample Transcript that will enlighten me?
Hi Steve,

I am not too proficient with the new feature either. But I have used
the following:

put "superSafe" into lpassword
encrypt field "myData" using "rc4" with password lpassword at 256
put it into someVariable

Hope this gets you started.
--
Best regards,
Mark Talluto
http://www.canelasoftware.com
Dar Scott
2004-11-29 19:53:50 UTC
Permalink
Post by Steve Bonham
I'd like to encrypt the password on closestack and write that to the
file. Then import and decrypt the password. But I don't understand the
Rev documentation for encrypt & decrypt. The following makes NO sense
to me at all...
encrypt source using cipher with [password|key] passorkey[and salt
saltvalue] [and IV IVvalue] [at bit ]
Can someone provide some sample Transcript that will enlighten me?
To get started, use this simplified syntax for the "password" method.
(The "key" method is less suited to those new to this.)

encrypt <source> using <cipher> with [ password ] <pass_phrase> [ at
<bits> bit ]

where that in brackets is optional and the <x> symbols are expressions.

This can be simplified to this:

encrypt <source> using <cipher> with <pass_phrase>

I plan to suggest a default cipher. If that idea is adopted, then the
command will simplify more.

If there is an error, 'result()' returns non-empty. The encrypted
value is in the variable 'it'. It will be larger than <source>.

Use "bf-cbc" to start for the cipher value. To find other ciphers to
try, use cipherNames()--except on OS X for now.

A current weakness is that the default "salt" value is empty, which
will make the encryption slightly weaker. This will probably be fixed
soon. For most people, procedures in using encryption have greater
weaknesses than this, so I wouldn't worry about it (for now). (Here is
how you crack a cipher with a Cray: You call up the company and ask
for the head engineer and offer him a Cray for the keys.)

The decryption is the same; replace 'encrypt' above with 'decrypt'.

Any value can be used for <source> or <pass_phrase>, but the
<pass_phrase> should not be trivial.

So, an example:

encrypt "Locker 3117, Penn Station" using "bf-cbc" with "Danger,
Will Robinson."

Dar

****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Steve Bonham
2004-11-29 20:36:55 UTC
Permalink
Okay Dar & Mark,

Thx for the input.

Tell me if I'm closer to understanding-

Let's say the hidden field "password" is "Jedi2004" (I'm requiring
that passwords to be one word).

to write to the external text file I can script...
on closestack
open file "settings.txt"
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
write it to file "settings.txt"
close file "settings.txt"
end closestack


This would result in some gibberish (encrypted data) being written to
the text file and this string would not be recognized as a password
if it were typed (or copied and pasted) into the ask password dialog.

Next time the standalone is opened, this script would work to
unscramble the encoded piece...
on preopenstack
open file "settings.txt"
read from file "settings.txt" until EOF
put it into EncryptedPasswordFromLastSession
decrypt EncryptedPasswordFromLastSession using "bf-cbc" with
"Danger, Will Robinson."
put it into field "password"
close file "settings.txt"
end preopenstack

This would result in "Jedi2004" appearing in fld "password" again?

-- and I can use any value for the pass_phrase so I could replace
"Danger, Will Robinson." with "Luke, Trust the force!" right?

Steve


--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Mark Talluto
2004-11-29 20:45:52 UTC
Permalink
Post by Steve Bonham
Okay Dar & Mark,
Thx for the input.
Tell me if I'm closer to understanding-
...snip

This will work just fine. I would need to know more about the purpose
of this password. If a user sent the .txt file to a friend with your
app, it would work just fine on the friend's system as well.

Is the purpose to lock the software to a particular system? or To
store user data?
--
Best regards,
Mark Talluto
http://www.canelasoftware.com
Steve Bonham
2004-11-29 21:16:25 UTC
Permalink
Mark/Dar,

The standalone is a game shell designed for use by teachers. They
will create the subject content to be imported into the Questions and
Answer fields.

You can see it at:
http://academics.georgiasouthern.edu/cet/SB/tw_jeop/

This web page contains some screen snapshots, movies of the game
being played, and the executable (still "beta") file. It works. But
right now the teacher can import a new game file (that they create)
and play the game. However once they quit and reopen the game all
their settings are reset to mine when I saved the standalone. The
settings.txt file will allow them to save their own preferences (game
times, categories, Questions and Answers, # daily doubles, row
values, password, etc.). Providing for encryption of this info
(especially the password) will allow the teacher to control the
default settings.

There are three cards;
1. a splash screen with an animation & some music
2. the "Game Room" where the game is played
3. the "Control Room" (access to which is password protected- every
attempt to open that card generates a "Please enter your password"
dialog box) where the game (via the "settings.txt" file) can be
modified.

The text file would contain the encrypted password- but unless the
un-encrypted password is provided as well the new user (distanced
learning students in this instance) could not get into the "Control
Room" to change the game. BUT when the student opens the game it will
automatically be configured as the teacher wants it to be.

Steve
Post by Mark Talluto
...snip
This will work just fine. I would need to know more about the
purpose of this password. If a user sent the .txt file to a friend
with your app, it would work just fine on the friend's system as
well.
Is the purpose to lock the software to a particular system? or To
store user data?
--
Best regards,
Mark Talluto
http://www.canelasoftware.com
_______________________________________________
use-revolution mailing list
http://lists.runrev.com/mailman/listinfo/use-revolution
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Mark Talluto
2004-11-29 21:29:20 UTC
Permalink
Post by Steve Bonham
The text file would contain the encrypted password- but unless the
un-encrypted password is provided as well the new user (distanced
learning students in this instance) could not get into the "Control
Room" to change the game. BUT when the student opens the game it will
automatically be configured as the teacher wants it to be.
Ok... your model will work just fine for this. Looks like lots of fun.
Where were these tools when I went to school? Oh well...
--
Best regards,
Mark Talluto
http://www.canelasoftware.com
Dar Scott
2004-11-29 20:56:10 UTC
Permalink
Post by Steve Bonham
on closestack
open file "settings.txt"
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
write it to file "settings.txt"
close file "settings.txt"
end closestack
Yeah, but the encrypted data is binary, so try this...

on closestack
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
put it into URL "binfile:settings.bin"
end closestack

Or use base64encode() if you need to have a text file.

Now you need to make sure no one will see your secret phrase "Danger,
Will Robinson."
Post by Steve Bonham
This would result in "Jedi2004" appearing in fld "password" again?
Yes, once you resolve the binary issue.
Post by Steve Bonham
-- and I can use any value for the pass_phrase so I could replace
"Danger, Will Robinson." with "Luke, Trust the force!" right?
Right.

This can be a confusing example to some folks, in that you are
encrypting something you call a password. This will work with any
data.

Of course you have to address the problem of what to do when there is
no settings file and what to do about folks copying settings files
(which might be nothing).

Dar

****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Dar Scott
2004-11-29 22:07:10 UTC
Permalink
Post by Dar Scott
To get started, use this simplified syntax for the "password" method.
(The "key" method is less suited to those new to this.)
encrypt <source> using <cipher> with [ password ] <pass_phrase> [
at <bits> bit ]
Whoops. I think it is more like this:

encrypt <source> using <cipher> with [ password ] <pass_phrase> [
at <bits> [ bit ] ]

The word 'bit' seems to be optional.

Dar

****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Robert Brenstein
2004-11-29 23:02:30 UTC
Permalink
Post by Dar Scott
If there is an error, 'result()' returns non-empty. The encrypted
value is in the variable 'it'. It will be larger than <source>.
I am curious why encrypt and decrypt are not functions (like
compress, base64, etc) but return the value in 'it'?

Robert
Dar Scott
2004-11-29 23:26:48 UTC
Permalink
I am curious why encrypt and decrypt are not functions (like compress,
base64, etc) but return the value in 'it'?
That's a good question. I can give my opinion that might hold you
until you get an authoritative answer.

1.
There are some optional portions. In most cases they can be simply
left empty, but in some cases you need a flat of some sort. So you
might have a seven arg function like this:

function encrypt source, cipher, usePassword, passOrkeyVal, useSalt,
saltOrIV, bits

2.
The other reason is error handling. The only option for a function is
throwing an error. (See try and throw in the Transcript Dictionary.)

The error in 'result()' and the data in 'it' are used other places, so
for many these are not new concepts.

You can make your own function, of course, and you can even use the
result to decide whether to throw an error.

Dar
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Frank D. Engel, Jr.
2004-11-29 18:33:00 UTC
Permalink
This helps to avoid another problem as well. If a one-second timer is
started at, say, 1:31:32, then the minute will be about half-over by
the time the display is updated, so that the time display is only
accurate about half of the time.

Of course, the timer may drift somewhat if there is a delay in
message-processing, depending on how it has been configured...
Post by Scott Rossi
Post by Richard Gaskin
Post by Dave Cragg
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something holding
up message processing, the timer may be late to update. Increasing the
frequency increases the chance of getting it right (but doesn't
guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
It could, but if one is after one second accuracy, for example, the
one-second timer will be thrown off, whereas the 1/10-second timer has the
opportunity to correct itself (assuming whatever issues delay the timer
don't take 3 seconds to execute).
Regards,
Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
W: http://www.tactilemedia.com
_______________________________________________
use-revolution mailing list
http://lists.runrev.com/mailman/listinfo/use-revolution
-----------------------------------------------------------
Frank D. Engel, Jr. <***@fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.
$



___________________________________________________________
$0 Web Hosting with up to 120MB web space, 1000 MB Transfer
10 Personalized POP and Web E-mail Accounts, and much more.
Signup at www.doteasy.com
Alex Tweedly
2004-11-29 19:08:56 UTC
Permalink
Post by Frank D. Engel, Jr.
This helps to avoid another problem as well. If a one-second timer is
started at, say, 1:31:32, then the minute will be about half-over by the
time the display is updated, so that the time display is only accurate
about half of the time.
Of course, the timer may drift somewhat if there is a delay in
message-processing, depending on how it has been configured...
You can solve both of those problems by doing something like

send myTimer to me in (1000 - (the millisecs mod 1000) ) millisecs

OK - it looks ugly, but it should line you up onto the second boundaries
quite simply.

In fact, the following script (with the addition of the obvious scrolling
field, and a "Stop" button") shows that there is some systematic drift of
up to 8 milliseconds (on my very SLOW Win2000 laptop).
Post by Frank D. Engel, Jr.
global gStop
on mouseUp
put 0 into gStop
put empty into field "Field"
send myTimer
end mouseUp
on myTimer
put (the millisecs mod 1000) into t
put t & TAB & the secs & TAB & the millisecs & cr after field "Field"
if gStop = 0 then
send myTimer to me in (999 - (the millisecs mod 1000) ) millisecs
end if
end myTimer
-- Alex.
Dar Scott
2004-11-29 19:27:15 UTC
Permalink
Post by Scott Rossi
"Can you script a more efficient timer?"
Here are some overhead times on my system:

Time to "send in time": 10 ns
Time to use an empty custom command: 34 ns
Time to process an _additional_ empty pending message: 21 ns

The last time applies if more than one message is ready. I'm not sure
about this one. It seems to be nonlinear; adding a pending message
might increase the time 0 ns or 100 ns.

It looks to me that using "send in time" is efficient.

One approach to making a timer more efficient is to minimize when the
field is updated. It takes about 1.5 ms to update a field. It takes
1.7 ms to update a field and then unlock the screen. Here are some
ideas:

Only update a field if the new value is not the same as the
previous.
Calculate the delay each time to make the next scheduled time at
100 ms after the second.
Do not update if the number of pending messages is greater than
some amount.

Even though it might take more time, you might want to experiment with
unlocking the screen after an update.

Dar


****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Scott Rossi
2004-11-29 19:28:08 UTC
Permalink
Post by Richard Gaskin
Post by Scott Rossi
Post by Richard Gaskin
Post by Dave Cragg
I guess Scott was concerned about the smoothness of the time display
ticking over. If you send every 1 second, and there is something holding
up message processing, the timer may be late to update. Increasing the
frequency increases the chance of getting it right (but doesn't
guarantee it).
Wouldn't any issues that would delay the firing of a one-second timer
also delay a 1/10th second timer as well?
It could, but if one is after one second accuracy, for example, the
one-second timer will be thrown off, whereas the 1/10-second timer has the
opportunity to correct itself (assuming whatever issues delay the timer
don't take 3 seconds to execute).
If a message were completely removed from the queue that would be an
issue. But if the message is merely delayed until the next idle,
wouldn't all messages that are due for firing get fired in their firing
order, regardless of the wait period specified when they were queued?
I don't quite follow what you're asking here (like Dave, my brain is
starting to ache), but it prompted me to try something else:

on runTimer
if not the uAllowTimer of me then exit runTimer
send "runTimer" to me in 100 millisecs
put the long time into fld 1
end runTimer

This handler immediately triggers itself again before doing anything, so in
theory, it should remain relatively consistent while being called only once
per second. However, taking a look at the CPU usage shows this simple
routine runs around 14% to 15% or so processor usage. The "wait x with
messages" apparently uses next to nothing. So while efficient script-wise,
"send in" appears to require significant more engine power to run. That's
my take on this anyway without knowing the details about Rev's inner
workings.

You may say "what's the big deal about 15% CPU usage?" It may not be an
issue for many folks. In my case, it is a big deal: moving images around a
card, swapping the icons of buttons, scrolling text in fields, all this
stuff adds up and places higher demands on the engine. Anything I can do to
reduce these demands enhances the ability of my apps to play nice with
others.

FWIW, I've come across other things that contribute to CPU use.
Scott Rossi
2004-11-29 19:36:24 UTC
Permalink
Post by Dar Scott
Post by Scott Rossi
"Can you script a more efficient timer?"
Time to "send in time": 10 ns
Time to use an empty custom command: 34 ns
Time to process an _additional_ empty pending message: 21 ns
The last time applies if more than one message is ready. I'm not sure
about this one. It seems to be nonlinear; adding a pending message
might increase the time 0 ns or 100 ns.
It looks to me that using "send in time" is efficient.
Actually, I was referring to "efficiency" in terms of placing demands on the
system, not in the amount of time to process within Rev. I agree that "send
is" is an efficient way to process stuff within Rev, but the surprise (for
me anyway) was that apparently using "wait x with messages" taxes the system
less than "send in". Or does it? Anybody at RunRev want to chime in?

Regards,

Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
E: ***@tactilemedia.com
W: http://www.tactilemedia.com
Dar Scott
2004-11-29 20:38:24 UTC
Permalink
Post by Scott Rossi
Post by Dar Scott
It looks to me that using "send in time" is efficient.
Actually, I was referring to "efficiency" in terms of placing demands on the
system, not in the amount of time to process within Rev.
Oh, I see what you mean. I used Activity Monitor on OS X and got this:

Send cycle (.1 s period): 16%
Default Button: 29%
Both: 35%

Send cycle (.05 s period) 35% (fluctuates a lot)
Send cycle (.01 s period) 101%
Send cycle (1 s period) 2%

I'm on OS X 10.3.6 using a dual 1.25 GHz G4.

Dar
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Frank D. Engel, Jr.
2004-11-29 21:53:05 UTC
Permalink
With send times that short, I would not be too worried about most of
those readings. The 2% usage for a 1 second timing is a bit more
meaningful, and even this is not too bad (though I suspect it could be
better).

Bear in mind that if running these tests in the dev environment, some
of that percentage will be due to added overhead of the development
environment. You should likely test this with standalone apps to get a
more meaningful measurement.

On a 500MHz G4 (OS 10.3.6), I created a new mainstack with a single
checkbox. The checkbox script is:

on x
send "x" to me in 1 second
set the hilite of me to not the hilite of me
end x


And the mainstack script:

on openStack
send "x" to button "Check" in 1 second
end openStack


I then saved this and saved it as a standalone. Activity monitor
(updating every 2 sec) reports:

The Rev IDE with the stack open (and no others): keeps shifting
between 0.5%, 1%, 1.9%, 2%...

The standalone app: about the same, except that it occasionally drops
as low as 0.4%, and I did see *one* flash of 3%.


Now changing the update interval to 0.5 sec:

CPU usage actually flashes from *zero* to as high as nearly 5%.


Now changing the update interval to 5 sec:

CPU usage switches from zero to about 1.9 or 2 percent.

Hint: most of the time (CPU perspective) the usage is zero. When
updating the checkbox, the usage can jump to as high as nearly 5% for a
brief period of time. My guess is that the activity monitor is biased
toward giving the higher readings.

I used the command-line 'time' utility to measure the runtime of the
standalone. The results after a few seconds were:

real 0m14.617s
user 0m0.890s
sys 0m0.230s

Combining user with system CPU time of the process yields about 1.12
seconds, out of 14.617 seconds that the process was running. This
would suggest about 7.7% CPU usage. Bear in mind that this includes
startup time, displaying the window, initializing the engine, etc.

Now after a somewhat longer run:

real 1m6.203s
user 0m1.200s
sys 0m0.350s

This suggests usage of 1.55 second over the course of 66.203 seconds,
for about 2.34% CPU usage. Notice that this is much lower, and this is
likely due to the fact that much of the startup time, etc. from the
runs is a "one-time" issue.


Next experiment:

I created a new mainstack and saved it, then saved it as a standalone
(no objects or scripts). Now I run the 'time' command on this
standalone:

real 0m47.594s
user 0m0.530s
sys 0m0.250s

This would be 0.78 second over 47.594 seconds, or 1.64% CPU usage --
with *NO OBJECTS OR SCRIPTS*.

This time is likely taken up by the Rev engine, so it would seem that
the actual CPU usage of my little checkbox mechanism is only about 2.34
- 1.64 = 0.7% CPU usage. Hmm....


You can't always judge a book by its cover.


Do note that these percentages will likely decrease slightly with
longer runtimes (flattening out because of startup time,
initialization, etc.), but I have no reason to run the tests for that
long, I think I made my point here.
Post by Dar Scott
Post by Scott Rossi
Post by Dar Scott
It looks to me that using "send in time" is efficient.
Actually, I was referring to "efficiency" in terms of placing demands on the
system, not in the amount of time to process within Rev.
Send cycle (.1 s period): 16%
Default Button: 29%
Both: 35%
Send cycle (.05 s period) 35% (fluctuates a lot)
Send cycle (.01 s period) 101%
Send cycle (1 s period) 2%
I'm on OS X 10.3.6 using a dual 1.25 GHz G4.
Dar
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
_______________________________________________
use-revolution mailing list
http://lists.runrev.com/mailman/listinfo/use-revolution
-----------------------------------------------------------
Frank D. Engel, Jr. <***@fjrhome.net>

$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten
Son, that whosoever believeth in him should not perish, but have
everlasting life.
$
Dar Scott
2004-11-30 01:10:58 UTC
Permalink
Post by Frank D. Engel, Jr.
With send times that short, I would not be too worried about most of
those readings. The 2% usage for a 1 second timing is a bit more
meaningful, and even this is not too bad (though I suspect it could be
better).
Many types of communications apps would need much better than 1 second
timing, of course. Some games might, too.
Post by Frank D. Engel, Jr.
Bear in mind that if running these tests in the dev environment, some
of that percentage will be due to added overhead of the development
environment. You should likely test this with standalone apps to get
a more meaningful measurement.
That's a good test.

However, I'm now getting 0% without the send cycle. Also, I'm not sure
what the dev environment would do but add maybe 20 ns each cycle as the
message rattles down the front scripts before getting to the right
script.

It might be all that overhead is in the event queue overhead, but I
would be surprised if it was.
Post by Frank D. Engel, Jr.
I created a new mainstack and saved it, then saved it as a standalone
(no objects or scripts). Now I run the 'time' command on this
real 0m47.594s
user 0m0.530s
sys 0m0.250s
This would be 0.78 second over 47.594 seconds, or 1.64% CPU usage --
with *NO OBJECTS OR SCRIPTS*.
This time is likely taken up by the Rev engine, so it would seem that
the actual CPU usage of my little checkbox mechanism is only about
2.34 - 1.64 = 0.7% CPU usage. Hmm....
.7% of 47.594 s is .333158 s
47.594 s / 5 s per cycle is 9 cycles
.333158 s / 9 cycles

That means an overhead of 37 ms per cycle.

That's the bad news.

The good news helps a little. In applications with more than 25
messages per second, several are done in a row, otherwise the message
queue would grow indefinitely.

Even so, I think this is an awful overhead. I want 1.1 ms or better.

I think I've made my point here. ;-)
Post by Frank D. Engel, Jr.
Do note that these percentages will likely decrease slightly with
longer runtimes (flattening out because of startup time,
initialization, etc.), but I have no reason to run the tests for that
long, I think I made my point here.
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************


****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Scott Rossi
2004-11-29 19:56:02 UTC
Permalink
Post by Scott Rossi
I don't quite follow what you're asking here (like Dave, my brain is
on runTimer
if not the uAllowTimer of me then exit runTimer
send "runTimer" to me in 100 millisecs
put the long time into fld 1
end runTimer
Sorry my mistake. This should have been:

on runTimer
if not the uAllowTimer of me then exit runTimer
send "runTimer" to me in 1000 millisecs # <--- 1 second
put the long time into fld 1
end runTimer

...which runs lower in terms of processor use. This is definitely a lot
less than sending 10 times a second, but the for me, the question remains:
is "send in" better to use than "wait x with messages"?

Regards,

Scott Rossi
Creative Director
Tactile Media, Development & Design
-----
E: ***@tactilemedia.com
W: http://www.tactilemedia.com
Steve Bonham
2004-11-29 20:48:18 UTC
Permalink
hmmmm

I tried the scripts I just posted.
Doesn't seem to work.

The "on closestack" script created a "settings.txt" file. But it is empty.

and nothing was imported back into the password field on preopencard
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Dar Scott
2004-11-29 21:06:21 UTC
Permalink
Post by Steve Bonham
The "on closestack" script created a "settings.txt" file. But it is empty.
That should be at least 24 bytes long. It should start out with the
word "Salted".

Add an error check:

on closestack
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
put the result
put it into URL "binfile:settings.bin"
end closestack

Does your version support encrypt/decrypt? What product and version do
you have?

Dar

****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Steve Bonham
2004-11-29 21:18:42 UTC
Permalink
I'm using DreamCard 2.5.

Steve
Post by Dar Scott
Post by Steve Bonham
The "on closestack" script created a "settings.txt" file. But it is empty.
That should be at least 24 bytes long. It should start out with the
word "Salted".
on closestack
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
put the result
put it into URL "binfile:settings.bin"
end closestack
Does your version support encrypt/decrypt? What product and version
do you have?
Dar
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
_______________________________________________
use-revolution mailing list
http://lists.runrev.com/mailman/listinfo/use-revolution
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Alex Tweedly
2004-11-29 22:36:34 UTC
Permalink
Post by Jan Schenkel
Post by Steve Bonham
I'm using DreamCard 2.5.
Steve
On the runrev.com website you cn find the differences
<http://www.runrev.com/section/platform.php>
When I opened the documentation to find more
information for the 'encrypt' command, I noticed at
the bottom of the text that it "is part of the SSL &
Encryption library"
So it could be that 'encrypt' doesn't work inside
Dreamcard --
Definitely the case - on http://revolution.runrev.com/section/whats_new.php
it says
Post by Jan Schenkel
Industrial strength encryption
Encrypt and decrypt data for all commerce and secure applications using
industrial strength encryption (Revolution only).
so it's pretty clear that it would not be supported in Dreamcard (and
certainly it never returns any value for me, in Dreamcard).
Post by Jan Schenkel
however, you can sue a simple 'compress'
--
put compress(field "password") into \
URL "binfile:password.bin"
--
put decompress(URL "binfile:password.bin") into \
field "password"
Or, since you never need to retrieve the password, but merely ensure that
it has been reproduced ....

put binarydecode("H32", md5Digest(field "password" & "my secret string"),
myVar)
put myVar into URL "file:password.hex"

and subsequently
put URL "file:password.hex" into correctValue
put binarydecode("H32", md5Digest(field "password" & "my secret string"),
myVar)
if myVar <> correctValue then
.... password is wrong ...
end if
Post by Jan Schenkel
It's always a good idea to include an md5digest in
your file to make sure nobody has tinkered it.
Yep. I'd go with that too, just to be extra sure no-one has tinkered with
it improperly.


BTW - if you are using Dreamcard, do you plan to distribute the stack with
the player ?
Dreamcard won't allow you to build standalones. If you distribute the
stack, you'll need to be careful about password protecting the stack - raw
stacks can be easily read in any "text" editor which could make your
password mechanism too clear to the enterprising student.

-- Alex.
Steve Bonham
2004-11-29 21:33:25 UTC
Permalink
okay- got an "ssl library not found" error when I tried:

on closestack
open file "binfile:settings.bin"
encrypt fld "mypassword" using "bf-cbc" with "Danger, Will Robinson."
--write it to file "settings.txt"


put the result
write it to file "binfile:settings.bin"
--put it into URL "binfile:settings.bin"
close file "binfile:settings.bin"
end closestack


I've also got Revolution 2.5. Do I have to make this an standalone
(with the SSL library included) to test it?

Steve
Post by Dar Scott
Post by Steve Bonham
The "on closestack" script created a "settings.txt" file. But it is empty.
That should be at least 24 bytes long. It should start out with the
word "Salted".
on closestack
encrypt fld "password" using "bf-cbc" with "Danger, Will Robinson."
put the result
put it into URL "binfile:settings.bin"
end closestack
Does your version support encrypt/decrypt? What product and version
do you have?
Dar
****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
_______________________________________________
use-revolution mailing list
http://lists.runrev.com/mailman/listinfo/use-revolution
--
--------------------------------------------------------------------------------------------------
Steve Bonham
Director, Faculty Technology Development Laboratory
Center for Excellence in Teaching - Georgia Southern University
Statesboro, GA 30460-8143
--------------------------------------------------------------------------------------------------
Dar Scott
2004-11-29 21:59:17 UTC
Permalink
Post by Steve Bonham
I'm using DreamCard 2.5.
I'm glad you brought this up. I don't have DreamCard and I wondered
what would happen.
Post by Steve Bonham
I've also got Revolution 2.5. Do I have to make this an standalone
(with the SSL library included) to test it?
I would think you could test the stack in Revolution 2.5. Then when
you make a standalone you might have to include the external, though I
would guess that it would be added for you automatically.

For your usage, almost any kind of scrambling might work. You can try
compression with a prefix string. Or ROT13.

(BTW, my oldest son now lives at Statesboro.)

Dar

****************************************
Dar Scott Consulting
http://www.swcp.com/dsc/
Programming Services
****************************************
Richard Gaskin
2004-11-29 22:08:42 UTC
Permalink
Post by Steve Bonham
I'm using DreamCard 2.5.
If all you need is lightweight encryption you might consider using the
fwPack and fwUnpack functions:

<http://www.revjournal.com/comments.php?id=P65_0_1_0>

While not nearly as secure as Blowfish, for modest needs they're fast,
easy to use, and are pure Transcript so no external parts are needed.

--
Richard Gaskin
Fourth World Media Corporation
__________________________________________________
Rev tools and more: http://www.fourthworld.com/rev
MisterX
2004-11-29 21:26:30 UTC
Permalink
Hi everyone,

Hope you had the great monday I had! So here's ma fonkee email for nofemba
2004!

Because Im in a great mood, I've restored all my links on Monsieurx and
here's my gracious contribution to help out the poor of us windoze boxes
users, work smooth and smooth as we usually like to...

If anyone can point me out to the mac and linux way of things, shortcut wise
regarding these keys, I'd really appreciate it for an improved tip...

And there's a Nitrous plugin coming to exploit this in all its variations
too! This weekend probably...

Why this script?

In moft windows, control-Tab (and control-Shift-tab) allow you to navigate
across different tabs in a tab pane in any application - except, you guessed
it, RunRev! Control-Tab hides the palettes while on the mac control-alt-tab
does - funny too, the tools menu hints at control-t which doesn't always
work! This is already is a bugzilla suggestion. Relax!

So pending N. Dayakar's email, and RunRev's network upgrade, my impatience
and fortuite skills, I told myself this should be trivial right?

well, it wasn't rawkeyup... it wasn't set the selectedline of btn thetabs ,
it wasn't set the hilitedline (or text) of btn thebats (for the trivia, it
wont work either, it's for fields only)... The right command was select line
2 of btn thetabs in a rawkeydown! Newbies, behold, even an expert tries it
all!

Scripting an english language like conversation with the computer would
imply a minimum of english language intelligence right? Go figure... Rant?
No, a long awaited XOS feature I want and getting closer each day!

But I go for the tabs right now... Here's your script N! You'll have to
adapt it to your button's name naturally... It was implemented as is and
tested into the new ControlsBrowser plugin soon available at MonsieurX.com
(some irrelevant parts of the script were removed to prevent confusion).

Sweet scripting dreams
Xavier
http://monsieurx.com
RunRev Nitrous Plugins
--

The following script should be inserted into a card script (first in the
line of events so that a card tabbed button will respond, If you have
multiple tabs, look at the focus functions in the revdocs to adapt it...

This script will interfere with the control-tab and control-shift-tab
commands to hide the palettes in the RunRev IDE. (see the environment
function in the revdocs if that causes a brain hemoragy.)

on rawkeydown k
-- if the environment is not "development"
-- if the platform is win32
if k is 65289 then
get "Controls"
if the hilitedtext of fld it is empty then exit rawkeydown
get "View
put the selectedtext of btn it into thisline
put btn it into views
put lineoffset(thisline,views) into thisline

if the shiftkey is down then
if thisline = 1 then
get the number of lines in views
else
get thisline - 1
end if

else

if thisline = the number of lines in views then
get 1
else
get thisline + 1
end if

end if

select line it of btn it

else
pass rawkeydown
end if
end rawkeydown
Chipp Walters
2004-11-29 23:55:26 UTC
Permalink
X,

what does

get "Controls"

do?

-Chipp
Post by MisterX
get "Controls"
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 265.4.3 - Release Date: 11/26/2004
N. Dayakar
2004-11-30 06:25:43 UTC
Permalink
On Tue, November 30, 2004 2:56 am, MisterX said:

[...]
Post by MisterX
So pending N. Dayakar's email, and RunRev's network upgrade, my impatience
and fortuite skills, I told myself this should be trivial right?
well, it wasn't rawkeyup... it wasn't set the selectedline of btn thetabs ,
it wasn't set the hilitedline (or text) of btn thebats (for the trivia, it
wont work either, it's for fields only)... The right command was select line
2 of btn thetabs in a rawkeydown! Newbies, behold, even an expert tries it
all!
[...]

Hi Xavier,

Thank you very much for script you have provided. Delighted to get the
response from the experts.

Regards,

Dayakar N

Jan Schenkel
2004-11-29 21:31:59 UTC
Permalink
Post by Steve Bonham
I'm using DreamCard 2.5.
Steve
On the runrev.com website you cn find the differences
between Dreamcard and the other Revolution editions :
<http://www.runrev.com/section/platform.php>

When I opened the documentation to find more
information for the 'encrypt' command, I noticed at
the bottom of the text that it "is part of the SSL &
Encryption library"

So it could be that 'encrypt' doesn't work inside
Dreamcard -- however, you can sue a simple 'compress'
/ 'decompress' pair as a subsitute codec :
--
put compress(field "password") into \
URL "binfile:password.bin"
--
put decompress(URL "binfile:password.bin") into \
field "password"
--

It's always a good idea to include an md5digest in
your file to make sure nobody has tinkered it.

Hope this helped,

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld)



__________________________________
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.
http://promotions.yahoo.com/new_mail
jbv
2004-11-29 21:40:35 UTC
Permalink
Post by Jan Schenkel
It's always a good idea to include an md5digest in
your file to make sure nobody has tinkered it.
it's also a good idea to include base64Encode / base64Decode
to avoid character sets differences between platforms...

JB
Jan Schenkel
2004-11-29 21:36:04 UTC
Permalink
[snip]
well, it wasn't rawkeyup... it wasn't set the
selectedline of btn thetabs ,
it wasn't set the hilitedline (or text) of btn
thebats (for the trivia, it
wont work either, it's for fields only)... The right
command was select line
2 of btn thetabs in a rawkeydown! Newbies, behold,
even an expert tries it
all!
How about using the 'menuHistory' property ?
--
set the menuHistory of btn "theTabs" to xxx
--

Hope this helped,

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld)

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Continue reading on narkive:
Loading...