World: r3wp

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

couldn't browse to any of the rebsites

same here for the past 10 hours at least.

working again now.

YEs

Ok, so there are going to be some issues about PAIR's that need discussion!

more than those you already noted ?

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?

You posted something on y

You just posted something on your blog...

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?

yes, right, there is even some code assuming, that rounding occurs 
automatically, which ceases to be true...

yep I see

and a round/half-ceiling is not good ?

the ceiling operation may be more reasonable than truncation for 
image dimensions

...but I do not have too strong preferences

I'm used to the truncation, though ceiling would work out too...

the only thing I'm not keen on is round/half-ceiling   :-)

in such "unclear" cases it may be even possible to require the user 
to submit "integral coordinates", I suppose you know what I mean?

ceiling would probably provide less bugs, since we don't end-up with 
zero values which are evil in division.

integral?: func [x [number! pair!]] [zero? x // 1]

Maxim, the problem is that the computation can vary + or - by the 
floating point precision of the full expression, so ceiling is not 
correct either.

Q will pairs *always* be floating point?

Yep.

In general, they work out nicely. But these edge cases must be solved.

hum... it would be nice for pairs to stay integer until they are 
cast into floating points... I can see many accumulation errors cropping 
up which will make sizing very hard to be pixel precise.

But, of course, the reverse is also true.