r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3]

Ladislav
10-Jul-2010
[3669]
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
]
Andreas
10-Jul-2010
[3670]
rename works fine on linux. but you'll only need it for encapped 
programs. no trouble directly overwriting the currently running .r
Ladislav
10-Jul-2010
[3671x2]
I guess, that shadwolf meant it for encapped programs
shadwolf?
Graham
10-Jul-2010
[3673x2]
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
10-Jul-2010
[3675x2]
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?
Graham
10-Jul-2010
[3677]
renaming won't work if there is a file lock on it
Ladislav
10-Jul-2010
[3678x2]
I tested it under Windows 7, it just works
Again, can you be more specific?
Graham
10-Jul-2010
[3680x2]
Hmm...  it does work!
Ahh.. but it locks the tmp-file instead
Ladislav
10-Jul-2010
[3682]
so what? that does not matter, does it?
Graham
10-Jul-2010
[3683]
so, to be sure you have to make sure that the tmp-file is not locked, 
or does not exist
Ladislav
10-Jul-2010
[3684]
yes
Graham
10-Jul-2010
[3685x3]
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
Ladislav
10-Jul-2010
[3688]
you can even insert wait 1 at the start of the UPDATE function to 
make sure the old version is not running any more
Andreas
10-Jul-2010
[3689]
well, you'd run update from within the old version, no?
Ladislav
10-Jul-2010
[3690]
yes, but you can even run it from the new one, if you are hasty enough 
;-)
Andreas
10-Jul-2010
[3691]
hehe :)
Graham
10-Jul-2010
[3692x2]
quit/call
call it quits
Ladislav
10-Jul-2010
[3694]
I see, that this should have been in the SDK group, not here. Sorry 
for being off-topic
Graham
10-Jul-2010
[3695]
Just blame shadwolf !
shadwolf
10-Jul-2010
[3696x3]
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
Andreas
10-Jul-2010
[3699]
just noted that rebol3 conversion to binary! always results in a 
network byte order (big endian) binary!, irrespective of host endianness; 
which is nice
BrianH
11-Jul-2010
[3700]
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.
Henrik
15-Jul-2010
[3701]
http://www.rebol.net/r3blogs/0326.html

Pairs as floating points
DideC
16-Jul-2010
[3702x2]
rebol.net is down fro me actually !?
fro=for
Graham
16-Jul-2010
[3704x2]
was down for me before
couldn't browse to any of the rebsites
Henrik
16-Jul-2010
[3706x2]
same here for the past 10 hours at least.
working again now.
DideC
16-Jul-2010
[3708]
YEs
Carl
16-Jul-2010
[3709]
Ok, so there are going to be some issues about PAIR's that need discussion!
Steeve
16-Jul-2010
[3710]
more than those you already noted ?
Carl
16-Jul-2010
[3711x2]
First, the math side of PAIRs as floats works out quite well.


However, there are some issues when converting to and from pixels, 
which are "quantized" as integers.

For example, now that:

>> 101x101 / 2
== 50.5x50.5

what is the size of this image:

>> make image! 101x101 / 2

?
Steeve, remind me, where did I note them?
Steeve
16-Jul-2010
[3713x2]
You posted something on y
You just posted something on your blog...
Carl
16-Jul-2010
[3715x2]
And more interesting... tell me the sizes of these images:

  img1: make image! 1.4x2.8

  img2: make image! 1.000001x2.999999


So, if you understand floating point, you see where I am going with 
this, no?
Perhaps Ladislav can bring some insight to this issue?
Ladislav
16-Jul-2010
[3717]
yes, right, there is even some code assuming, that rounding occurs 
automatically, which ceases to be true...
Steeve
16-Jul-2010
[3718]
yep I see