World: r3wp

would it be possible (in general) to encapsulate the whole R2/3 GUI 
functionality incl. antigrain etc. into a lib, usable for other languages 

 as a out of the box GUI generator? communication & event handling 
 e.g. via TCP?

R3 is that lib

However, it still fails to be as easy to integrate as for example 
a 0MQ library

I've been out of the loop here the last few months but it seems like 
R3 is stalled again. And I do not see any signs of Carl. What's the 
overall status here?

there has been a lot of work going on with a few R3 projects.  a 
few extensions, the gui, etc.

there has also been quite a bit of work done on Red.

Any HAM-Radio guys here? Maybe this is the best channel to get in 
contact with Carl.

:D

My brother did it in the past, but sold the equipment. I really wonder, 
what are Carl's thoughts, as even my dog understands, that REBOL 
situation is in deep .... :-)

I notice ++ and --, which was discussed here:
http://www.rebol.net/cgi-bin/r3blog.r?view=0057#comments

Would it be ok to let NEXT and BACK do the job, like this:

next: func [series] [
	either word? series [
		set series system/contexts/lib/next get series
	][
		system/contexts/lib/next series
	]
]

Examples of use:

>> blk: [a b c]
== [a b c]
>> next blk
== [b c]
>> blk
== [a b c]
>> next 'blk
== [b c]
>> blk
== [b c]

it would break a lot of code, and in fact, I prefer it like it is. 
  


this being said, if we have ++/--, then I expect *these* to work 
as you just depicted

WIll it break code? Hmm, what kind of code?

all of my code  ;-)

I don't see how. Notice, NEXT in my example works just like today 
with all arguments beside words, which gives an error today.

The first part of my examples above use the new NEXT just like the 
old NEXT, we have today.

ahhh.. I just re-read your code... and was bitten by the lit-word 
evaluation again.

I didn't realize that:

either word? series [

triggers when you give a lit-word.

in this case, you are right.


except in implementation.   words carry their binding, you don't 
need (in fact shoudn't) acess it via system   

set word next get word

should be enough.

If just using NEXT instead of full path, R3 will create a stack overflow. 
The function is called NEXT, you know! ;)

But anyway, this should be changed in the native.

I guess, the reason for the stack overflow is that function body 
is rebound to local context.

ok... I just hit myself on the head a few times.  clearly, I'm not 
sharp right now.  :-)

Winblows mess with your mind! Save yourself! :)

yeah, I guess that's it.  my brain is getting fried by the sun going 
through the windows (our first full week of sun in months).

Geomol, the return values of ++ and -- are different than those of 
NEXT and BACK, which is why we have the seperate functions.

NEXT and BACK are also non-modifying (except for ports), which is 
another valuable difference.

Are you sure, that's why we have separate functions? What benefit 
is there from the return values of ++?

By "valuable difference" I don't mean that one or the other behavior 
is preferable all of the time and so we should choose one, I mean 
that both patterns of behavior are valuable in different circumstances 
and so we need to support both. Both sets of functions are needed 
in mezzanine code, as they are now.

Yes, I am sure. The different pattern of behavior was why Carl added 
++ and --, since he needed something like this for mezzzanine code.

My viewpoint is, that ++ isn't the speedy native, many people would 
expect. When using ++ on a series, a new series is created. So ++ 
take one series and produce two, one is the original, which is incremented, 
the other is the return value, which is the old series position. 
This isn't very effective from a performance perspective.


If my NEXT function was implemented in the current NEXT native, it 
didn't have to produce another series, if called with a word. This 
will mean good performance.

++ doesn't create a new series, it just increments the index of the 
reference to the same series.

Same could be done with many other natives, if they were improved 
to also take words as arguments.

It does create a new series:

>> b: [a b c]
== [a b c]
>> same? ++ b b
== false


(I know, it's the same area of memory, but we have two set of series 
variables to work on that memory.)

A series reference fits into a value slot, so returning a reference 
to the same position doesn't take any more space than returning a 
reference to a different position. This means that there is nothing 
to be gained by losing the information.

Are you saying, e.g. an integer value take up the same amount of 
memory as a series ref.? Doesn't sound very effective, but you could 
be correct. :)

(Remember a series need info about the area, the head, tail, position.)

++ and -- return a reference to the previous position in order to 
lower the need for local temporary variables to save the previous 
position when you need to. Returning it means that information is 
not lost. Technically, since ++ and -- are modifying functions they 
don't need to return anything at all. The only reason they return 
that information is because it's valuable.

Yes, an integer takes up the same space as a series ref (though the 
series itself takes additional space). Though in R3 currently integers 
are 64bit and series refs are a 32bit pointer and a 32bit offset, 
so it's not as much of a waste as in R2 where integers are 32bit. 
For both though, the value slot is 128bit anyways. This is the price 
you pay for using variants.

This is from R2:

>> next b
== [b c]
>> stats/series
== [34304 26141 7434 231 498 497 406]
>> next b      
== [b c]
>> stats/series
== [34304 26145 7444 231 484 483 409]
>> ++ b
== [a b c]
>> stats/series
== [34304 26151 7454 231 468 467 412]
>> ++ b        
== [b c]
>> stats/series
== [34304 26157 7464 231 452 451 415]


You see, NEXT increment BLOCKS (2nd number) by 4 each time. ++ increment 
it by 6 each time. So ++ take up more memory.

I think, you assume too much, my young padawan! ;)

In R2, ++ and -- are mezzanines which I wrote, not natives. You are 
assuming too much :)

The R2 versions are optimized for R3 compatibility, not for efficiency. 
They are still efficient for mezzanine implementations of that behavior.

:) TouchŽ!

On the other hand, I really don't know how to interpretet the results 
of R2's STATS function, so I'm taking your word for it that the series 
are created by the ++ calls. Which numbers tell you this?

Got it. Series are 32 bit pointer and 32 bit offset. So no additional 
space is wasted by having ++ return as it does.

SAME? must work from the same index in the same series:

== [a b c]
>> same? a next a
== false

Henrik, yes. I'm trying to point out, that an additional index is 
created.

Brian, do

? stats


in R2. I read it, as the /series refinement show BLOCKS as the second 
number.

And a block here is a series index. Two blocks can share the same 
mem area for the actual content of the series.

The area, head, tail and such attributes of a series are in the series 
itself, not in the reference to the series. This is good because 
series references are copied every time they are passed to a function 
- REBOL is strictly pass-by-value. All return values are copied too.

Makes sense. So the additional mem for the series ref. is on the 
stack (or whatever data structure is used), and if that area is reused 
between additional computations, no mem is wasted by ++. Correct?

>> stats/series
== [16384 11618 4590 25 151 150 199]
>> a: [1 2 3]
== [1 2 3]
>> stats/series
== [16384 11623 4601 25 135 134 202]


Only one of those is the new block - the rest are overhead of either 
the STATS function or of the REPL loop itself, or runtime overhead, 
or call overhead, or assignment overhead. I'm starting to think that 
STATS/series isn't very useful.

Yes, stats/series eat 3 blocks each time, it's called.

No mem is wasted by ++ that isn't also wasted by NEXT.