Re: Reloading a changed stack file

2008-09-28 Thread Björnke von Gierke
Try the revert command, it's perfect for this, assuming you do replace  
the stacks on the hard disk, and are not creating new files.


On 28 Sep 2008, at 14:31, Len Morgan wrote:

I'm back again with an autoupdater question.  I have an  
application that is made up of a bunch of stacks.  Each stack as a  
custom property cstkVersion that carries the current version number  
of that stack.  On my server, I have the latest versions of all the  
stacks and a text file that contains lines of the form:

stackfilename,stackversion

I have one get the ball rolling stack that checks itself against  
the latest version and then downloads the latest version if the  
versions are different.  This part seems to be working fine although  
I do require the user to quit the program and restart it if it has  
been updated.  This whole process is started up by a stand-alone  
that launches this first stack and is simple enough that the stand- 
alone should only require changing when the engine changes.


Now to the real problem/question: As I'm going through my text  
file of stack names/versions, I have to check the cstkVersion  
property of each stack on the user's hard drive against the version  
listed in the text file.  In order to read the property, the stack  
has to be loaded into memory.  My problem is how to I get rid of  
this in-memory copy and replace it with the new version (assuming  
that I had to download a new version)?


Is it as simple as:

if tVersionUpdated then
  stop using tCurrentStack
end if

and then when I really need the stack, another start using  
stack ... ?


The documentation for reload stack indicates that this is used to  
prevent two stacks with the same name being loaded at the same  
time.  If I don't pass the message on, I'll have the old and the new  
stack in memory at the same time.  I understand how this might cause  
problems.  If I pass the message on, what happens?  Does it purge  
the current version from memory and then load the new one?  Does it  
throw and error?  Does it go ahead and load the new version too and  
then decide which one messages will be sent to?


Is there another command or function that will purge the stack  
currently in memory and reload the new and improved version from disk?


Thanks for any clarity you can provide.

len morgan

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Reloading a changed stack file

2008-09-28 Thread Chipp Walters
On Sun, Sep 28, 2008 at 7:31 AM, Len Morgan [EMAIL PROTECTED] wrote:

 My problem is how to I get rid of this in-memory copy and replace it with
 the new version (assuming that I had to download a new version)?

 Is it as simple as:

 if tVersionUpdated then
   stop using tCurrentStack
 end if


Revert can work. I like to use the 'delete stack' command as well for this
sort of thing. It forces the removal of a stack from memory.

if tVersionUpdated then
   delete stack tCurrentStack
   go stack tCurrentStackFilename
end if
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


re: Reloading a changed stack file

2008-09-28 Thread Len Morgan
Try the revert command, it's perfect for this, assuming you do replace  
 the stacks on the hard disk, and are not creating new files.


 On 28 Sep 2008, at 14:31, Len Morgan wrote:


This sounds like what I'm after but when I tried this, I observed something 
that may throw a monkey wrench (spanner on the other side of the pond) in the 
works.

After checking all the versions of my stacks, I opened the Application Browser 
and the only stacks showing were ones that had actually had some code run.  I 
was under the impression that merely getting custom property from a stack 
caused it to be loaded into memory but since it doesn't show, what exactly 
would revert revert to?

Also, the documentation on the revert command says that it only applies to the current stack.  
Since these stacks are not showing up in the application browser, if I later issue a start using stack 
xyz will it use the copy that is hidden in RAM, or will it reload a fresh copy from the 
hard disk?

len morgan


 I'm back again with an autoupdater question.  I have an  
 application that is made up of a bunch of stacks.  Each stack as a  
 custom property cstkVersion that carries the current version number  
 of that stack.  On my server, I have the latest versions of all the  
 stacks and a text file that contains lines of the form:

 stackfilename,stackversion

 I have one get the ball rolling stack that checks itself against  
 the latest version and then downloads the latest version if the  
 versions are different.  This part seems to be working fine although  
 I do require the user to quit the program and restart it if it has  
 been updated.  This whole process is started up by a stand-alone  
 that launches this first stack and is simple enough that the stand- 
 alone should only require changing when the engine changes.


 Now to the real problem/question: As I'm going through my text  
 file of stack names/versions, I have to check the cstkVersion  
 property of each stack on the user's hard drive against the version  
 listed in the text file.  In order to read the property, the stack  
 has to be loaded into memory.  My problem is how to I get rid of  
 this in-memory copy and replace it with the new version (assuming  
 that I had to download a new version)?


 Is it as simple as:

 if tVersionUpdated then
   stop using tCurrentStack
 end if


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Reloading a changed stack file

2008-09-28 Thread Björnke von Gierke
I'd say the Application Browser is the last place to look at for  
verifying the existence of running stacks in rev. But you are right  
about the need for a current stack to revert, but if it's the current  
stack then it's always in memory. To change the current stack, you can  
use the defaultStack property.



On 28 Sep 2008, at 22:57, Len Morgan wrote:

Try the revert command, it's perfect for this, assuming you do  
replace   the stacks on the hard disk, and are not creating new  
files.


On 28 Sep 2008, at 14:31, Len Morgan wrote:


...
Also, the documentation on the revert command says that it only  
applies to the current stack.  Since these stacks are not showing  
up in the application browser, if I later issue a start using stack  
xyz will it use the copy that is hidden in RAM, or will it reload  
a fresh copy from the hard disk?






--

official ChatRev page:
http://bjoernke.com/runrev/chatrev.php

Chat with other RunRev developers:
go stack URL http://bjoernke.com/stacks/chatrev/chatrev1.3b3.rev;

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


re: Reloading a changed stack file

2008-09-28 Thread Stephen Barncard
The application browser needs to be manually refreshed for the latest 
info. Look for a little icon at the bottom of the scrollbar that will 
refresh the list.



After checking all the versions of my stacks, I opened the 
Application Browser and the only stacks showing were ones that had 
actually had some code run.  I was under the impression that merely 
getting custom property from a stack caused it to be loaded into 
memory but since it doesn't show, what exactly would revert revert 
to?


Also, the documentation on the revert command says that it only 
applies to the current stack.  Since these stacks are not showing 
up in the application browser, if I later issue a start using stack 
xyz will it use the copy that is hidden in RAM, or will it reload 
a fresh copy from the hard disk?


len morgan



--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Re: Reloading a changed stack file

2008-09-28 Thread Richard Gaskin

Chipp Walters wrote:


On Sun, Sep 28, 2008 at 7:31 AM, Len Morgan len-morgan at crcom.net wrote:


My problem is how to I get rid of this in-memory copy and replace it with
the new version (assuming that I had to download a new version)?

Is it as simple as:

if tVersionUpdated then
  stop using tCurrentStack
end if



Revert can work. I like to use the 'delete stack' command as well for this
sort of thing. It forces the removal of a stack from memory.

if tVersionUpdated then
   delete stack tCurrentStack
   go stack tCurrentStackFilename
end if


One cautionary note for newcomers:  the delete stack command is a 
sometimes command - sometimes it does what it says, other times it 
does what you want. :)


Delete stack doesn't delete the stack if the stack in question is a 
maintstack.  With mainstacks, it merely removes it from memory, and has 
no effect on the existence of the file on disk.


But when using delete stack on a substack, it will delete indeed the 
substack from the stack file, which may or may not be what you want.


This bifurcated behavior warrants some caution, at least until we get a 
true purge command, which seems a more sensible option when what we 
want to do is purge a stack without deleting it:

http://quality.runrev.com/qacenter/show_bug.cgi?id=1081

I tend to use revert myself, so I don't have to worry about whether 
the stack is a substack or mainstack.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution