World: r3wp

Don't assume that it will store slot values. The reason that Rebin 
is being used in the host interface is to make the internal layout 
of the slot values something you don't see, so that it can change 
for different platforms.

Rebin is supposed to be compact - that is its other purpose (reducing 
line overhead for network protocols).

ok ok, nice draft

Could it mean that we will store complex data structures (nested 
series and object without duplicated values, like MOLD do) ?

actually it would be a true reversal mold

(loadable mold)

In theory, that is its intention. In practive I don't know about 
binding issues.

so if i take another example, i could do a save in rebin format of 
the screen gob, then reload it and being in the same state i was 
when i saved it ?

cool feature for graphic applications

That does sound cool.

because i am

it would be a new way to make screenshots

and your screenshot contains the whole application, you can test 
it  in the state it was when i done the capture

is that not a too powerfull feature for  humanity ?

Carl could be afraid and not release it

That would be affected by binding issues. Rebin is still partly in 
Carl's head, under development. I can't answer some things :(

it was actually Geomol on 8-Apr, who too refused to submit bugs, 
as those might not be corrected anyway


Pekr, I don't refuce to submit bugs! I have submitted bugs after 
we discussed it here. I just see little point in submitting bugs. 
And I have the practical problem with finding time to submit all 
the bugs, I could. But I do something, I consider even better than 
submitting bugs in the current situation. I have done some development 
lately, that test the REBOL scanner deeply. I have collected all 
my findings in a document, that I'll give to R3 developers, when 
I'm finish. The scanner is just one part of REBOL though.

That would be great, thanks :)

If you want to really test the scanner, test TRANSCODE. There is 
already one bug ticket in for a change in TRANSCODE's behavior, and 
I know of another bug that is worth reporting. If we find more bugs 
that we can fix, that would be great.

I just see little point in submitting bugs.


If you are talking about bugs in stuff that is mostly designed but 
not fully implemented (like money!, or maybe vector!) then they are 
worth reporting if they haven't been reported already - just don't 
expect an immediate fix, since we may not be working on those yet.


If you are talking about bugs in stuff that is still being designed 
(like the GUI) then reporting problems in R3 chat is better. 


If you are talking about bugs in stuff that hasn't been designed 
yet but may have a placeholder (like task! or utype!) then don't 
bother.

If you are talking about bugs in what we are working on (there's 
a roadmap) or requests for new behavior then report them asap :)

I don't like the behavior of parse regarding hyphens after delimiters, 
although it's the same as in R2 and there said to be needed for parsing 
csv data
 
>> parse/all {, ", ,} ","
== ["" { "} " "] ; this is as I expect

>> parse/all {, ," ,} ","
== ["" " " " ,"] ; I would expect == [""  {" } " "]

Do you mean double-quotes? A hyphen is this: -

sorry, then double quotes

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