World: r3wp

one trivial but important question: 


OK rebol is a programing language that get most of its interest when 
used in the internet area.

So for example i use my brand new software made in rebol  it connects 
to internet and check for version update.

Updating a software from the software itself is a common feature 
now in day.


But with rebol how do we do that mechanics ? ok i can log to the 
webserver where are stored the release i can do a CRC comparasoin 
betwin 

my software and the  one on the distant server repository. So i get 
to know if the repository is different from the version installed 
on my computer.

Once my local copy is aware the distant repository evolved i can 
download the new copy.

And that's where the poblems appears ... I can't make the new version 
downloaded from the server to be subtituated like all the other software 

made in c, C++ etc... does. What i mean is i can do 97% of the update 
from the webtask but the automatic stop the current app and launch 
the new version is 
not possible...


if you want to better understand what i mean think about your firefox 
update for example

 at your firefox start it performs a version check then download the 
 new version
then close the current running firefox and launch the new one.

Does rebol 3 will introduce that kind of mecanics ?

in fact that i current software download the new version install 
software then starts the new version install software and curent 
version is terminated  install software then doeas the substitution 
process then starts the new software version.


But this means the software can launch a sub process which will not 
be terminated when the current process is terminated with an quit 
call for example.

and since rebol script are  most of the time very tiny in size  i 
don't see the interest of having an updated scheme looking like what 
is done on the other laguages. I htink it should be a cool thing 
to be able somehow to substitute anytime the file on my computer 
and then  autoreload it in memory without having to restart the application 
and if i could trash out  from memory of the VM the previous script 
that wuld be even nicer ....

Script autoreloading is not a simple task because scripts are primarily 
run to cause side-effects, even if those side effects are only in 
memory sometimes. So reloading a script means upgrading a script. 
The R3 module system was designed to allow modules to be upgraded 
in place, by making the previous module state available to the initialization 
block of the new module. This allows the new module to migrate the 
data of its old version.

Be careful though, you have to design your modules for this on purpose, 
you can't just count on it happening automatically. Module state 
migration is not difficult, but it is a different process every time 
since it depends on what state you need to migrate. The R3 module 
system can make it possible, but your module needs to do the actual 
work.

the automatic stop the current app and launch the new version is 
not possible...

what stops you from simply CALLing the new app and then QUITing?

This is essentially what several of my applications do to restart 
themselves. Not quite what you want, but as close as I could get:
   http://www.rebol.org/ml-display-message.r?m=rmlPPPJ

you can't overwritte the script currently running it's locked 

that why an intermediary intaller is used in general but this in 
not suited for rebol or scripting langages in general

sunanda yeah i know we can get close to the real deal but we can't 
get the real deal ... and i think it will benefit rebol image to 
have the real deal

[The partially solution I adopted allows replacement of all scripts 
except the top-level driver]

yeah in fact i could do this check the version then download the 
new version from server maning the file .TMP then create from my 
script a install-app.r  and call it then close the current app

and have that temporary script install-app.r to rename the .TMP file 
to my main script and then start the app. It could display popup 
message like "Configuring the new version please be patient..."

but it's lot of work for a thing i will be the only one to use ... 
and that's not the meaning of my ask ...

but then how to detect in the install-app.r that the min script we 
want to replace is not locked anymore ?

and wait until it does

There is a solution using RENAME, at least I think that a version 
using RENAME works, did you try it?

the function doing update could work as follows:

update: func [
    {updates the current application}
    application-file [file!] {the current application}
    tmp-file [file!] {a temporary file}
    source {updates from this source}
] [
    if exists? tmp-file [delete tmp-file]

    ; now we can rename the application-file, since the tmp-file does 
    not exist

    rename application-file tmp-file ; I guess, that this works, even 
    if the application is running?
    write/binary application-file read/binary source
    call application-file
    quit
]

rename works fine on linux. but you'll only need it for encapped 
programs. no trouble directly overwriting the currently running .r

I guess, that shadwolf meant it for encapped programs

shadwolf?

Ladislav, your update function won't work in Windows

The easiest way to do this is to maintain your source in an encrypted 
and signed compressed binary.  So, you have the stub which does the 
update and executes the source.  It checks for new source, overwrites 
the old one and then executes it.  Since it is not updating the exe, 
there are no file locking issues.

Ladislav, your update function won't work in Windows
 - as far as I can tell, it works even in Windows

Can you be more specific?

renaming won't work if there is a file lock on it

I tested it under Windows 7, it just works

Again, can you be more specific?

Hmm...  it does work!

Ahh.. but it locks the tmp-file instead

so what? that does not matter, does it?

so, to be sure you have to make sure that the tmp-file is not locked, 
or does not exist

yes

Well this is very interesting if this works.

consistently

So, the point is that you can't delete the running binary, and you 
can't delete it even if you rename it first, but you can rename and 
write a new binary in its place

you can even insert wait 1 at the start of the UPDATE function to 
make sure the old version is not running any more

well, you'd run update from within the old version, no?

yes, but you can even run it from the new one, if you are hasty enough 
;-)

hehe :)

quit/call

call it quits

I see, that this should have been in the SDK group, not here. Sorry 
for being off-topic

Just blame shadwolf !

yeah blame :)

i'm not talking about .EXE i'm talking about script

if it would have been asked in sdk people would had complain ... 
Ok straigh I don't care where I post  what is important is the answer

just noted that rebol3 conversion to binary! always results in a 
network byte order (big endian) binary!, irrespective of host endianness; 
which is nice

Shadwolf, for scripts, there is no file locking. So the process is 
much easier if you are getting and writing the new script, saving 
your data, shutting down and starting up with the new script (similar 
to what Ladislav's function is doing for exes). If you just want 
to reload the script in place in the current interpreter instance, 
you have to do the live state migration I mentioned above.

http://www.rebol.net/r3blogs/0326.html

Pairs as floating points

rebol.net is down fro me actually !?

fro=for

was down for me before