World: r3wp

Just downloaded R3-a49 release and Gui Demo is working ( text view 
isn't ) but I can't get simple window to show :(

Examples from http://www.rebol.net/wiki/GUI_Examplesare not working.... 
:(
I get missing this missing that... :(


I just want to show simple text in a window, or a button... am I 
asking to much ? :)

could you be more specific? what did you do that caused the examples 
not to work?

Also the GUI is only working under Windows at this time.

vlad: remember to add load-gui to your scripts

Brian: do you have proof that value slots are bigger in R3? I'm not 
aware of it being compiled for 64bit system (thus, no 64bit pointers), 
and there's more than enough space in 16 bytes to hold a 64bit integer!

Well I downloaded r3-a49 and started it. Typed Demo, and only when 
I press View-text error happens... other parts are working fine...
Could be that missing load-gui is a problem :) oopss

no, this is an old bug that has not been fixed in the demo.

view-text is broken quite some time. But when you try to use your 
own gui, you really have to use load-gui first ..

Error: "cannot parse the Gui dialect at: 'ts read-string main.r button 
Huge"

And thanks, load-gui did the job :)

Actualy, load-gui is not requested if you manage yourself gobs and 
events.
You just have to open the event port and add your handler into.

This is the very minimalist event handler i use to do my tests on 
gobs and events.
then, just add your gobs into the main screen gob

set 'screen system/view/screen-gob
unless system/view/event-port [
	system/view/event-port: open [scheme: 'event]
]
system/view/event-port/awake: func [event /local gob offset ev][
	ev: map-event event
	gob: ev/gob 
	offset: ev/offset 
	switch event/type [
		move [...]
		up [...]
		down [...]
		...
	]
	tail? screen
]

append screen make gob! [...]
do-events

and a show screen before the do-events, indeed

Gabriele, all I have is a memory of Carl saying so, and that memory 
is likely 1.5+ years old, from back in the early days of R3 (2007).

My God... path notation (with parents) is faster than PICK  to get 
a value from a serie with a calculated index, even in the current 
R2.

t/(x) faster than pick t x


I was always thinking  the reverse since a while (true in older R2 
release).
How may this happen to me, i'm fooled...

I discovered in the middle of Tretbase development that (first, second, 
third, etc...) were faster than pick also.

And the using parens is comparatively slow:

>> fastest [s/(++ i)] [++ i s/:i]

The first code took 0:00:00.005777

The second code took 0:00:00.004147


>> fastest [s/(random 26)] [j: random 26 s/:j]

The first code took 0:00:00.007947

The second code took 0:00:00.005672

..in R3

but perhaps not in R2:

>> fastest [s/(random 26)] [j: random 26 s/:j]

The first code took 0:00:00.016884
The second code took 0:00:00.024865


>> fastest [s/(i: i + 1)] [i: i + 1 s/:i]

The first code took 0:00:00.021479

The second code took 0:00:00.017246

I tend to use 'pick because at least I get none back and not an error!

That's one of the changes in R3:

>> s

== "abcdefghijklmnopqrstuvwxyz"


>> s/27

== none

what i don't understand, it that:
>> dt [loop 1000000 [x: x + 1 pick t x]]
== 0:00:00.706

>> dt [loop 1000000 [pick t x + 1]]
== 0:00:00.521

when using DP, i can see that the second case do much more evaluations 
than the first one.
How can this be possible ?

it's illogic Mister Spok,

so doing:
>> ++ x  t/:x
is to 2 times faster than:
>> pick t x + 1

Astounding...

in the past PICK was the fastest method to deal with calculated indexes

Geez... i have to rewite a bunch of scripts beacause of that

but does t/:x still return none when the index doesn't exist? cause 
that is the main advantage of pick for me...

by the term "still" above, I really mean when compared to the pick 
method.

Perter showed you that is the case now in R3.
t/:x == none
if the index X doesn't exist in T

*Peter

So i can make this announce.
PICK is USELESS now in R3, don't ever use

... it  anymore

Except if you don't want functions evaluated.

uh !?

b: reduce [does [print "hi"]]

Here are my results:

>> include %timblk.r
== 1.55177304964539E-2
>> x: 1
== 1
>> t: [1]
== [1]
>> t/:x
== 1
>> t/(x)
== 1
>> pick t x
== 1
>> time-block [t/:x] 0,05
== 4.09841537475586E-7
>> time-block [t/(x)] 0,05
== 4.84228134155273E-7
>> time-block [pick t x] 0,05
== 2.98023223876953E-7

showing, that PICK is the fastest

Steeve: you are not executing the same thing : in the second case, 
x does not advance it's always x +1 with x static. In the first case 
x is incrementing so the pick is not the same at each loop, so it 
depends of t length.

>> x: 1
== 1


>> t: "sldfhg ksdjlfgh sjkdfhgsjkdfhgjksdhfgjkhsdfjkghsdjkfhgkjdhfgjkdghfdjkh"

== {sldfhg ksdjlfgh sjkdfhgsjkdfhgjksdhfgjkhsdfjkghsdjkfhgkjdhfgjkdghfdjkh}

>> dt [loop 1000000 [x: x + 1 pick t x]]
== 0:00:00.406

>> dt [loop 1000000 [pick t x: x + 1]]
== 0:00:00.359

>> dt [loop 1000000 [pick t ++ x]]
== 0:00:00.265

Here, only the length of the code block is explaining the time difference 
(7, 6 or only 4 instructions to interpret).

So, if the following is faster it's because the code block evaluation 
take less time IMO (3 instructions) :

>> x: 1 dt [loop 1000000 [t/(++ x)]]
== 0:00:00.172

Ladislav: I get different results from you. I'm running A49 on Mac 
OS X:

>> fastest [t/(x)] [pick t x]

The first code took 0:00:00.003794

The second code took 0:00:00.004753

>> fastest [t/:x] [pick t x]

The first code took 0:00:00.002759

The second code took 0:00:00.004285

What OS did you run your tests under?

By the way, it is probably far too early to come to any conclusions 
about the relative speeds of different functions in R3 as I believe 
the code has not been optimised yet.

Brian: then my memory is that R3's value slots are not fixed size 
any more, because they will be bigger on 64bit systems, but the current 
version is still 16 bytes per slot. so, you can't trust it being 
that way across versions, but i don't think there are versions that 
use more memory yet.

my OS: Windows XP Prof SP3

Didec, i have the same results than Peter with the A49.
And what you're saying is not the problem i pointed.

See, there something strange with the number of evaluations done.

>> dp [loop 1000000 [pick t x + 1]]
== make object! [
    timer: 517292
    evals: 4000011
    eval-natives: 2000004

>> dp [loop 1000000 [t/(x + 1)]]
== make object! [
    timer: 350263
    evals: 3000011
    eval-natives: 1000004


So the conclusion is that evaluating a path don't  follow the same 
scheme than a block evaluation.

actually resolving a path is faster than calling a native function, 
it was not the case in the past

my Linux results (Mepis 6) show the same pattern as Windows XP

aha, you are using A49, sorry

A49 yields:

>> time-block [t/:x] 0,05
== 1.23858451843262e-007

>> time-block [t/(x)] 0,05
== 1.9371509552002e-007

>> time-block [pick t x] 0,05
== 4.35829162597656e-007

So why is 'pick so much slower?

It may be caused by the change in function algorithm passing, which 
is more complicated, due to multithreading support