World: r3wp

It cannot be part of ALTER function as ALTER can be used with any 
series. I'm not sure how you could strore the counts in bitsets or 
strings;-)

one-liner version:
alter-count: func[
	block [any-block!]
	value [any-type!]
][

 pick change block: any [find/tail/skip block :value 2 insert tail 
 block :value] 1 + any [block/1 0] -1
]

More than ALTER, I would like
	append-if-necessary
	remove-if-necessary
(but probably with better, shorter names)

huh ?

yeah! i posted my first modification on devbase

even if i have don"t access to alpha T_T

hum * i haven't an access

i have some difficultes to construc devbase.r , missing icons in 
the title, any idea ?

sorry , i got no problem in fact (i just have to open my eyes)

everything should download automatically

These alter-count functions aren't taking R3 into account. Most of 
these key/value usage patterns will be handled by the map! type in 
R3.
; alter-count, just code since it's too simple for a function
key-counts/:key: 1 + all [key-counts/:key 0]

Whoops: all -> any

not agree, how do add new key with your code ?

Like that.

Doesn't work in R2, but this is the !REBOL3 group, isn't it? :)

The trick is that you can't remove keys, but if you assign none to 
the map at a given key the effect is the same.

i see

The general pattern in R3 is that none is the equivalent of missing 
data. Pick off the end of a series returns none too.

more tolerant functions

throw less errors

Recovering from a none is easier and more efficient than recovering 
from an error. Series bounds are just an implementation detail anyways, 
when you have series that can autoexpand.

Does that mean I won't be able to build the equivalent of an R2 hash! 
with map! in R3?


I use a hash! to build a unique list of words as it was far quicker 
than any other method I could come up with.

Yeah, hash! has been replaced with map!, which is faster but more 
specialized. You could either use block!, assign true to the map! 
at the word key, or keep a word count.

this works in R2

 key-counts/:key: 1 + any [select key-counts :key  do [repend key-counts 
  [:key 0] 0 ] ]

key-counts/:key: 1 + any [select key-counts :key do [repend key-counts 
:key 0] ]

forget the second

Thanks for the suggestions: I think that I'll have to use  a map! 
with a dummy value as using a block! was too slow.

I'm missing hash! in R3 because with map! I cannot use integers as 
keys... I hope it will be changed.

It's hard in hash! as well, but I agree. There is some missing infrastructure 
around the map! type as well, like iteration and searching.

has the conversation moved elsewhere?

no, it is just some kind of slow-down period. Activities around R3 
should be renewed as we speak, it seems Gabriele and Cyphre will 
be back on R3 full-time soon. There is also draft of release strategy. 
It seems RT decided (upon suggestions) to divide R3 release, so we 
should see Core like R3 alpha in one month, View will come later 
(2 - 3 months)

I should have figured... December is a slow month

I gleaned some good news from Docbase: work has started on implementing 
unicode support :-)

Yes, this is Carl's main focus now.

That is great news. How far along is it?

As for unicode, first draft should be in few days, or that is how 
I understand it :-)

Pekr, thanks Pekr, that is encouraging!

Does this mean that R3 will not become available in DevBase for several 
more months?

R3 mezzanines are already in devbase

Yes, but does this mean that R3 as a running system will not be available 
in DevBase for several more months?

what do you mean by "running system"? if you mean the R3 version 
of DevBase, I don't think it will be possible until VID3 is advanced 
enough.

No, I mean the R3 product that was promised for two weeks ago

it was? :-)

Yes

where did you read that?

Carl wrote it on his blog

so he hasn't yet gotten rid of the bad habit of posting estimate 
times... don't believe them. :-)

Believe me, I have stopped believing

I'm just trying to get some information

As I think I've mentioned (a million times) I would want those estimates 
never to be published. They are wrong 99% of the time anyway.