World: r3wp

Interesting. The changes are quite small.

actually, it could be because mine is not compressed.

That's a possibility. I'll try to compress your script tomorrow if 
I have time (it's late here) and see if it segfaults.

I'm trying to sort files by modification but it's not working.  sort/compare 
files: read %/c/ by-date: func [a b] [to-logic attempt [greater? 
modified? a modified? b]]

sort/compare files :by-date

does anyone use this type of code?

What exactly does Pending mean in Curecode?

Nicolas, sort/compare does not work in R3. This bug is in Curecode: 
 http://curecode.org/rebol3/ticket.rsp?id=161&cursor=8

It would be nice to see that one fixed, especially if it is easy 
to fix.

Pending means someone (me, usually) has already written a fix and 
submitted it to DevBase, but it's not built into R3 yet.

Carl's fixes don't get marked pending, he just builds them.

I don't understand a lot of these complaints where people say they 
can't contribute because REBOL "isn't open source". Large chunks 
of R3 were written by me, and every line I wrote was open source, 
freely available in DevBase.

A lot of REBOL is written in REBOL, and all of that is open source 
(in theory). The source is all in DevBase.

By the way, hash! being gone is not even in the top 100 drastically 
incompatible changes in R3. It's a new language :)

BrianH, then my fixes fit under the Pending category :-)

Yup, as long as they are submitted to DevBase. I mark fixes as pending 
before they are even accepted in DevBase, so pending doesn't mean 
inevitable. Some pending fixes have been dismissed (mostly requests 
for new functions).

I keep the new functions in my archives for later submission to the 
community library, if they are worth saving.

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