World: r3wp

Yeah I do that now with stuff such as:

>> myfind: func [s v][find/any s v]
>> myfind "God is Great" "G?e"
== "Great"


I'll look into 'apply as I have been wanting to dig deeper into what 
REBOL3 is offering.

http://www.hmkdesign.dk/rebol/files/4b1cf5b6f8dbd87dfc957a59e16dcf4e-107.html

so now we can do a little bit of skinning :-)

Henrik, that is sick (meaning very good).

now things are moving. yesterday: select new skin after closing and 
opening window. today: switch between multiple skins on the fly in 
the same window. tomorrow: .... multiple skins simultaneously in 
the same window. :-)

Are rebol2 core programs going to work on r3?  Is another alpha of 
r3 about ready to be released?

the next R3 release will be unicode based. It will not be very compatible 
with R2 programs. A few scripts and one-liners will run.

Louis, you may have read about it,  but at one point there was even 
a discussion that R3 could not be called REBOL anymore, due to the 
numerous changes in the language caused by Unicode. It was decided 
not to change it.

so yes, there will be many compatibility issues, but it will definitely 
be for the better.

I remember that. I wrote r3 because it's easier.  :>)   Perhaps it 
should just be called 3.  That  is even easier to write.

Will we have another alpha soon?

as soon as the Unicode internal alphas are debugged, yes

I don't know if the next VID3 will make it in there. View does not 
yet support unicode, AFAIK.

Unicode in core is what I'm wanting to play with for now.  Thanks 
for responding.

you're welcome

REBOL 3 Datatypes and Typesets http://rebollovesjerry.blogspot.com/2008/03/blog-post_15.html

Nice!  You put together that blog nicely.  Your illustrations are 
excellent.

Thanks Paul, I am doing my best.

:)

Jerry,


I'm actually reading your blog to improve my Chinese. I guess it's 
a  'side-effects' .

And I am actually reading Carl's blog to improve my English. It is 
a side effect for sure.

>> probe first jerry-rebol-blog/readers
== [self  yeksoon]

I wrote a lengthy post, hoping to start a constructive discussion 
on how we could increase Rebol's popularity and enbiggen (I know 
it's not a real word, but I didn't want to use "increase" twice in 
one sentense :P) it's userbase. I hope this is something more people 
are thinking about now that Rebol 3 is imminent. Please have a look 
at http://www.reboltalk.com/forum/index.php/topic,1513.0.html


(I'm not trying to draw people away from Altme, but I think there's 
a need for a good Rebol forum too! :))

; a wee difference people probably noticed otr is documented
; R2
>> form first datatypes
=="end"
;R3
>> form first datatypes
== "end!"
; there is also a difference with get
; R3
>> t: 42
>> get  't
>> get :t
>> get t
; in R2 only the first is not an error

; In R3
>> get 42
== 42

Interesting. I wonder if that is intentional.

; In R3
>> a: context [b: 42]
== object!
>> get 'a/b
== 42
; In R2
>> a: context [b: 42]
>> get 'a/b

** Script Error: get expected word argument of type: any-word object 
none
** Where: halt-view
** Near: get 'a/b

from !Altme

Anyone that wants to take part in the testing that is required for 
REBOL3, drop a note here and we can synchronize what words are in 
need of a test case file.  Don't worry, there are many.   All we 
need to avoid is redundancy (well not really as more tests are infinitely 
 better than no tests.)   If you are keen to start, of the word dictionary; 
I'm in the A's.  :)  So if you start at D or E of F we probably won't 
collide.

Carl's preferred method are small focused tests.   and: [
    [equal? 1 and 1 1]

    [error? try [1.0 and 1.0]]   ; and is not expected to handle decimal!
]

etc... for the gament of 56 types by 68 actions that REBOL needs 
to handle for us.  The test case files usually focus on few actions 
with lots of various types. 


Note;  A lot of the tests can be based on R2.  The basic operators 
need to function at or beyond R2, so an R2 test that fails R3 is 
important.


I'll find out if the basic-test-engine.r script these case files 
are based on is for public consumption for those that want ot help 
out.  It really is a fair grunt of typing and thinking about edge 
cases (after all the baby step core cases)

Note; with the recent blog post; this basic-test-engine.r  may wel 
become part of the build-basic-test-engine-scripts.r reflective test 
generator.  As Carl points out; these are not better than human written. 
 They may cover more bases but still require a lot of attention to 
detail.   My interest in all this is mainly to keep Carl and RT away 
from the potato peeling work, freeing them for building new things. 
 :)

Are we going to see a 'currentpoint type of word for 'draw in R3? 
 something that will tell us where we are on the drawing surface?

This is for using draw to do a print preview.

where we are
 - do you mean in rich text?

Not necessarily.  If using AGG fonts, I want to know where I am so 
I can calculate how much space I have left on a line.

Can someone set me up an account for R3-Alpha?

graham, that is in rich text then. i want access to metrix, text 
bounding box, and so on. hopefully we'll get that eventually.

Reflection in REBOL 3.0 http://rebollovesjerry.blogspot.com/2008/03/reflection.html
, For English version of this article, hit the "Google Translate" 
Link in the page.

the first OSX version of R3 is released internally. it's currently 
only for unicode testing purposes, so there is no networking or graphics 
yet.

While feeling stupid giddy today, starting working on the Zen of 
REBOL.  But
>> import 'this
doesn't have the same Zen oomph as
>>> import this
maybe I'll leave it alone.

can anyone help , im new to rebol. im trying to pass a value to a 
function but i get a path error. why? ex. somefunc: func [x] [print 
series/x]

and use it to read a value in a series somefunc 1

This may be what you want:
   series: ["a" "b" "c" ]
   somefunc: func [x] [print pick series x]
   >>somefunc 1
   == a

This works in recent versions of REBOL:
   somefunc: func [x] [print pick series/:x]
note the ":" before the "x"

series/:x or series/(x)

oops -- remove the 'pic from that second example:
    somefunc: func [x] [print series/:x]

thank you that worked the .x didn't but the (x) did

It wasn't a .x, it was a :x in his example - try that.

that works too

thanks

This was in response to a question from Jerry: And what is "the new 
behavior of function!" that you mentioned?
Cross-posted by request.

Jerry, R2 just had one kind of context (2 if you include the autoexpand 
context used by system/words). Functions, objects and USE all used 
this type of context, and words were bound to this kind of context. 
A function! in R2 is bound to one of these contexts, which gets reused 
when the function is called. When the function is called recursively, 
the value block of the context is pushed on a stack but the context 
is reused - this is the main reason R2 could never be thread-safe. 
The only difference that object! contexts have over function! or 
USE contexts is that the word 'self is added to them.


In R3, there is at least one more context type: stack-relative, which 
is used by the function! type. All of the words bound to a function! 
resolve their bindings relative to the context in the executing stack 
frame, rather than directly. When a function! starts it allocates 
a context on the stack; when it ends it deallocates the context. 
This means that the context of words bound to a function only exists 
when the function is running, so there is no point to referring to 
these words outside of the function. Although this slows down word 
references, it speeds up function! calls and reduces potential memory 
leaks due to word references in functions after they have returned. 
This slowdown in word references is the reason that R2-style rebcode 
doesn't make sense to add to R3 without some changes to its semantic 
model to make up for the difference.


A closure! in R3 is like a USE call in R2 (USE in R3 is implemented 
using closure!). The words are direct-bound to a context (so word 
references are faster), but it creates a new context and bind/copy's 
the code block at the beginning of each closure! call. There is still 
no point to bind a word to a closure's context when the closure isn't 
running, since the next time the closure runs it will create a new 
context, but it does make sense to use a context created by a closure 
call after the closure has returned since it is a regular context 
like a R2 USE context. In general, it is better to use function! 
unless you need to refer to the context after the closure! returns 
- mostly useful for generators, currying and other functional programming 
tricks.


In R3, object! contexts are like the R2 system/words context: they 
can expand, but not shrink; closure! and function! contexts can't 
expand though. There will be further changes to the way object! contexts 
work, and module! contexts will behave the same way.