World: r3wp

The function with the most incompatible changes in R3 is LOAD. There 
were many errors in R2's LOAD that have been fixed in R3. Almost 
every feature of LOAD is different, in sometimes subtle, sometimes 
drastic ways.

I am happy that you guys exist :)

Graham, VID+ was being worked on in order to get the core in good 
shape, by uncovering bugs and helping set priorities for fixing them. 
Now we are fixing the most important core bugs, including the one 
that has been blocking infrastructure development the most: the lack 
of a decent, working module system.

Now the thing blocking us is the lack of a multitasking model, so 
we are (mostly Carl is) implementing what we need to get multitasking 
working: memory protection and a new system object. It looks like 
we will have a shared memory model after all, rather than a shared-nothing 
approach. It's still up in the air though.

PeterWood, don't store the associated values in a map! as #[none} 
- that removes them from the map!. Use #[true] instead.

Shadwolf, the design of the map! type is pretty-well finalized already. 
It's the implementation that still needs work :(

Also, don't base serious development on alpha software unless you 
can afford to finish your development after it's no longer alpha 
:)

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
]