World: r3wp

yes, you need to hack the event engine a little bit.   


As gregg says, you need to have a memory of the last move event to 
get its position  and store it (you can do this with an event-handler). 
 glayout and GLASS do this for handling scrollwheel events.


what I also do is find the top-level face which is under the mouse-cursor 
and fire off my own events from the scroll-wheel instead of relying 
on a text field.

again, you can trap the scroll-wheel events in the event handler.


if you want to have a ready-made solution, download glayout.r from 
rebol.org  and look at the hacked WAKE-EVENT function.


it already does all of this and wraps it up by adding new function 
you can add to your face/feel  object in order to handle scroll-wheels.

the wake-event function needs a few other functions which are all 
in the glayout module, but it should be easy to keep just what you 
need and run that before the rest of your script.

Thanks for the help, I am still digging around, will let you know 
the result. I will have to translate all that to RebGui though.

Is there a better way than this to convert a block to string, then 
back to block?
blk-to-send: reduce ['my-function 1 2 3]
str-zmq: mold blk-to-send
blk-received: first to-block str-zmq
Thanks for the help!

use LOAD instead of FIRST TO-BLOCK

Thanks Rebolek!

Is there a way to start the word browser directly without going thru 
the viewtop?

do http://www.rebol.com/view/tools/word-browser.r


You can <alt>-click (or right-click) icons in the viewtop to see, 
where the script come from.

Awesome

Is there a way to to get the time in a datetime value without using 
refinement?
>> d: now
>> d/time
== 12:09:58

Is there something like select d 'time OR pick d 'time ? Thanks.

>> fourth now

== 13:23:31

Works in both REBOL 2 and 3.

This works in R3:
   >> pick now 'date
    == 30-May-2011

This is cool! Thanks!

I encountered another problem:
>> 1.48297457491612E-2 + 0.985170254250839
== 1.0
>> arccosine/radians 1.48297457491612E-2 + 0.985170254250839
** Math Error: Math or number overflow

** Near: arccosine/radians 1.48297457491612E-2 + 0.985170254250839

>> arccosine/radians probe (1.48297457491612E-2 + 0.985170254250839)
1.0
** Math Error: Math or number overflow

** Near: arccosine/radians probe (1.48297457491612E-2 + 0.985170254250839)
>> arccosine/radians 1.0
== 0.0

That's a rounding problem. You can check such numbers in R3 by:

>> to binary! 1.48297457491612E-2 + 0.985170254250839
== #{3FF0000000000001}
>> to binary! 1.0                                     
== #{3FF0000000000000}

I don't understand it, from 'probe', it seems like it already returned 
1.0, why arcosine/radians still get > 1.0

>> system/options/decimal-digits: 17
>> to decimal! #{3FF0000000000001} 
== 1.0000000000000002

>> (1.48297457491612E-2 + 0.985170254250839) = 1.0
== true

decimal-digits tell, how many digits, you wanna see. But when you're 
out there at 15-17 digits, you can't count on the last one, so it's 
choosen to be not seen.

= (or equal?) is not exact. Use == (strict-equal?)

>> (1.48297457491612E-2 + 0.985170254250839) == 1.0
== false

Makes sense?

Ok, I got it now. Thanks Geomol!

welcome

Is there a best practice for such situation? Always rounding to 0.0000000000000001 
?

well, I just tried (R2):
>> (1.48297457491612E-2 + 0.985170254250839) == 1.0
== true

In R2, integers are 32 bit, in R3 64 bit.

sorry, 1 second :)

Hm, you may have a serious problem. Let me see...

:) REBOL2 can't do math. Thinking, if a struct! can help.

Hahaha :)

>> arccosine/radians probe round/to (1.48297457491612E-2 + 0.985170254250839) 
1E-15
1.0
** Math Error: Math or number overflow

** Near: arccosine/radians probe round/to (1.48297457491612E-2 + 
0.985170254250839) 1E-15

>> arccosine/radians probe round/to (1.48297457491612E-2 + 0.985170254250839) 
1E-14
1.0
== 0.0

You can look at the internal of decimals in R2 with struct! like 
this:

	d: make struct! [v [decimal!]] none

 i: make struct! [lo [integer!] hi [integer!]] none	; assuming little 
 endian

>> d/v: (1.48297457491612E-2 + 0.985170254250839)
== 1.0
>> change third i third d
== #{}
>> i/lo
== 1
>> d/v: 1.0
== 1.0
>> change third i third d
== #{}
>> i/lo                  
== 0

In first case with the addition, i/lo is 1, and 2nd case, it's 0.

I don't have time to dig into it deeper now. But if you find a simpler 
way to check these things, post it.

You can see the bit patterns with this code:

	do http://www.fys.ku.dk/~niclasen/rebol/libs/bit.r
	enbit i/lo
	enbit i/hi

What does 'third d' actually represent?

Also the bits in some order depending on endianess, I guess.

If I got it correctly, using struct, we get access to the internal 
representation of decimal in R2. Then the third value in the struct 
is the number behind the comma, and we divide it into two section 
using struct! i, which will then reveals the last number. Hope I 
get it right.

Third value is the full 8 bytes (64 bit) for decimals. As integers 
are 32 bit in R2, we split the 8 byte decimal in 2 times 4 byte integers. 
Third i also give the full 8 bytes.

Decimals are in IEEE 754 standard. See: http://rebol.net/wiki/Decimals-64

That doc is meant for R3 though, so things like setting system/options/decimal-digits 
won't work in R2.

Ok, I think I got the idea. Thanks for looking into this! For now 
I'll stick with round/to x 1E-14 for practical reason. But it's very 
nice that I learned deeper about how decimal works and handled.

The PROBE function is not reliable in this case, you can use e.g. 
MOLD/ALL:

>> mold/all 1.48297457491612E-2 + 0.985170254250839
== "1.0000000000000002"

when you're out there at 15-17 digits, you can't count on the last 
one
 - that formulation is rather confusing

exact comparison in R2, comparing 1.48297457491612E-2 + 0.985170254250839 
with 1.0 :

>> 1.48297457491612E-2 + 0.985170254250839 - 1.0
== 2.22044604925031E-16


This demonstrates, that the result of the expression is greater than 
1.0

The whole issue is caused by the fact, that Carl decided to "hide" 
some issues, that are "more honestly exposed" by other programming 
languages. Usually it looks, like the "arithmetic hiding in REBOL" 
helps, but there are cases like this, where the result of hiding 
is worse, than if the arithmetic was "honest".

Thanks, Ladislav. You nailed it better, than I could. About the last 
digits, I meant, that we can count on 15-17 decimal digits of precision. 
I guess, it's more precise to say, that the decimal! datatype has 
15.95 decimal digits of precision.
See: http://en.wikipedia.org/wiki/IEEE_754-2008#Basic_formats


For the new ones, an often used example, where math with IEEE 754 
floats (in all languages) gives unexpected result is:

>> 0.1 + 0.2 - 0.3
== 5.55111512312578E-17

I guess, it's more precise to say, that the decimal! datatype has 
15.95 decimal digits of precision.

 - the most precise is to say, that it has (usually) 53 binary digits 
 of precision. That can be "transformed" to 15.95, but such a "transformation" 
 is quite uniformative, since it ignores some important facts

Fact #1: the representation is binary, and it cannot represent exactly 
even the numbers representable using just one decimal digit

Fact#2: 16-digit decimal numbers cannot be used to represent "exactly 
enough" the IEEE754 binary numbers