World: r3wp

Janko, thanks :)

wow, now you are focusing on multitasking.. that is a big core thing 
... if there will be shared memory model we can probably build various 
other abstractions on top of it (I did observe some backslash vs 
pure message passing / actors lately also -- especially for concurrency 
on the same computer / cpu ) ..  this is interesting thinking IMHO 
http://clojure.org/state"Message Passing and Actors" under "I chose 
not to use the Erlang-style actor model for same-process state management 
in Clojure for several reasons:"

well he uses quite complex thing in form of persistent (functional 
-imutable (versioned)) data structures... that is probably something 
too complex to focus on now.. but if we have simopler / more primitive 
means of concurency we can probably build stuff on top of it .. and 
even try with some fancy data structures (factor folks were playing 
with them so they are doable)

persistent here doesn't mean it's in a db or a file but it means 
that data structures in clojure are immutable and theoretically when 
you change one you always get a new copy so threads can't break stuff 
to other threads in the middle of process, but the catcth is that 
that copy is not really a copy (which would be simple and *expensive*) 
but same structure reused with some different paths so that it is 
different ( I hope I made any sense ) .. he explained it in some 
video very nicely

Shadwolf: re R3 richtext; R3 will have the posibility to get all 
useful information at the font glyph level. The richtext module is 
able to give us all that info internally. We only need to design 
interface at the Rebol language level.

BTW even in current R3 version you can get the proper width/height 
 using SIZE-TEXT command. But I believe the final version will offer 
even more.

(Here you can see what can be done with the current R3 in ~5kb script. 
http://www.rebol.cz/~cyphre/stuff/r3-richtext.jpg)

New SYSTEM object: http://www.rebol.net/wiki/R3_Releases- This is 
what I've been waiting for :)

Most of the map! bugs were fixed too :)

It is just yet another version of system object. For me still kind 
of chaotic.

Devbase contains detailed list of stuff which is going to be a 3.0 
release. The link is not supposed to be made webpublic though ....

Why can't a map! be sorted?

seeing that I have Windows 7 running under VmPlayer, I decided to 
try the r3 beta and can report that I does work :) The only problem 
was with the demo/Reactor. When I tried on open an examples file,Windows 
complained about the file type. The same thing does not happen on 
XP Pro ?

I =it

Ammon, map! doesn't even have a order at all, just a temporary display 
order. It's a set of pairs.

Set in the mathematical sense.

The map! type is not a series, it's more like an object with different 
inclusion rules. No order, no position.

so just for a lookup?

Pekr, where you see chaos I see the design process. R3 is being designed 
as we go. It's a work of art - I mean that in a literal sense, not 
as a compliment. Open projects usually grow, or fail. The preplanned 
ones usually fail.

Interesting...


I'm using blocks to manage a lot of name/value pairings which I will 
sort and copy/part the top x items.  I was hoping to be able to utilize 
the speed of map! for doing this.  Maybe I should use map! while 
creating/modifying and then when it comes time to pull top x items 
I could convert it to a block...

map! is for lookup and deduplication, yes.

Ammon, converting map! to block! is the usual method of doing that, 
yes.

Ok, good enough.  I think that will work.  I'll modify some of my 
scripts to use that method and then do some benchmarks...

BrianH: don't you mind that we have 'map function, which is complatly 
unrelated to map! datatype? I mean - sometimes we use shortcuts - 
e.g. 'context for make object! ... so I thought it might confuse 
a bit to have map func, which does something unrelated?

While I have your attention and I'm thinking about sorting I just 
thought I'd mention that I'm using the following work-around for 
the lack of /compare in sort:

; R3 /compare bug work around
sort-compare: func [
	blk
][
	; disorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	; sort em
	sort/skip/reverse blk 2
	; reorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	blk
]

The map! type is used extensively in the GUI, and some mezzanines. 
The MAP function's name wasn't my idea - some Haskell fan thought 
we needed a map function (true) and that it should be called the 
same thing (not REBOL-like). This came before the name of the map! 
type was chosen, and prevents us from making a proper functional 
map function of that name. At least we already had a fold-like function 
with a REBOL name: REMOVE-EACH.

I really wanted the map punction, but I don't mind it being called 
anything else, I agree with pekr's reasons

map function is similar to apply, no?

Ammon, that is a known (already submitted) bug, and not the only 
SORT bug. Work in progress :)

It is even similar to new  'resolve func in the same regard as to 
'apply func. It just maps something to something else

I love the MAP function, but it could really use a *-EACH name since 
it is in that family. We're probably stuck with the name :(

Oh, I *really* love RESOLVE - already backported it to R2 :)

hmm, then you could say the same for apply too, and probably foreach 
should be renamed to for-each, etc :-)

I know it's reported and in CureCode.  I'm just saying that I'm working 
around it now in the hopes that the priority might be bumped up a 
bit. =D

wow, great release.. ithings are moving

APPLY doesn't act like a *-EACH. Backported that too :)

Ammon, right now we're working at a lower level. It's high priority 
:)

BrianH: what is 'resolve good for? Couldn't it be achieved with some 
mixture of difference, intersect, and such? :-)

Hmm, R3 is whole new REBOL. So far I am using at R2 level. I have 
my own old map func, which maps some object fields from other object. 
Now I need to learn how 'resolve could be usefull.

Not as quickly, and those work on blocks, not objects.

then object should be a series :-)

Resolve is good for assignment of values in objects to other objects 
without them having to be in the same order or even have all the 
same fields. If anything, it makes objects even *less* series-like 
than they were before :)

RESOLVE is *fast*, even in the R2 mezzanine version, much faster 
than the typical ugly loop it replaces.

Here's the R2 version of RESOLVE:

resolve: funco [
	"Set known values in target from those given by the source."
	target [object! port!]
	source [object! port!]
	/only from [block!] "Only set words listed here (exports)"
][

 set/any bind either only [bind/copy from] [words-of source] target 
 get/any source
	also target set [source target] none
]

I think. The /only changes are still being tested. Here's the pre-/only 
version:

resolve: funco [
	"Set known values in target from those given by the source."
	target [object! port!]
	source [object! port!]
][
	set/any bind words-of source target get/any source
	also target set [source target] none
]

It took a lot of thought to get that code so small :)

It takes a lot of thought in order to understand the code (for me) 
:-)

Darn, /only doesn't work there. I was trying to come up with it on 
the fly and I failed, miserably :(

The version without /only works perfectly.

It works in R3 of course. I just haven't had the time to backport 
the changes in the last 9 alphas (in two weeks) to R2-Forward yet..

Sorry, 10 alphas in 2 weeks :)