World: r3wp

I think I have a fix for the guest N bug in chat.

Carl recommending hash! here:
http://www.rebol.com/article/0020.html
Second thoughts for R3 here:
http://www.rebol.net/r3blogs/0052.html

And some refinements to the redesign here:
http://www.rebol.net/r3blogs/0137.html

look the what's wrong part of the articles you gave sunanda that's 
clear

2. You cannot use keys directly as indices.

damn !! for a hash table using keys as indice isn't it the what is 
it all about thing ?

1. All values are keys, even the content values. ... stupid since 
they can't be indice

you want me to continue puttinf  dot on i and bars on T  sunanda 
or you got why hash! is meaningless ?

3. You cannot add new values using the key value assignment form. 
->>  too bad ... so i can't do cycling tables using hash inidice 
wich is lesson 3  for  C  programming any  decent university

You have no control over case-sensitivity for hashes.

So, what do we want to do about it? We are at a point where we need 
to finalize the hash datatype for REBOL 3.0. It is possible to make 
some change

and since doing some change in an incomplete things is worst than 
redoing it from scratch then it's better to forget about it and create 
map!

here's some map! doc - http://rebol.net/wiki/Map- isn't it replacement 
for hash!?

btw - we have 'map function. This is imo confusing. We sometimes 
use shortcuts, e.g. for make object! we have 'context. Will not users 
expect 'map being a shortcut for make map! ?

btw - it was extremly difficult to find above Map link. The DocBase 
structure is completly twisted.

can't be more clear on the matter

A map is an name-to-value associative array. It uses hashing for 
high performance. Sometimes this kind of association is also referred 
to as a dictionary. 


The map datatype replaces the R2 hash datatype. The motivation for 
this replacement was that some people in the user community felt 
the design of the older hash datatype was confusing, since it hashed 
both keys and their data. The new map datatype just hashes keys. 
Data is not hashed.

when do you need hash ... hum when you deal with a database to make 
a cashing system to not have to use the database access on any request 
for example

or when you want to do a similar thing like a dictionnary (for search 
engine design are widely derived from hash table concept)

or more simply to be able to travel through a large number of complexe 
data

the faster possible

so what you are trying to say is - positive, or negative? I somehow 
don't understand, what you mean by all of that :-)

it's only a technology  some usefull stuff for the one needing them

for the one that doesn't need them well ... they don't need it but 
if you have to reduce a langage to only what only 1 specific guy 
need you will not go any far

hash! being redisigned and enhanced how could i get that as a lame 
thing that great I don't know personally if it will benefits me  
but it's cool to have this for the one needing it

The "more 3365" error in chat is because we are not under the correct 
topic, when trying to get that file. I will try to figure out how 
to fix that.

for example for the area-tc (which renders full live colored text) 
during long time I expected to organise the date to parse or the 
line as hash! to be able to locate them faster  (since my data structure 
was pos char color making hash getting the position as indice was 
a good idea (well a much better idea was proposed by steeve simpler 
but all mighty efficient)

but in R2 hash! keys can't be indice and all is key so i never get 
to get a hash table based system

for area-tc project

shadwolf - then it is time to start to move your project to r3, no? 
I think that View kernel itself might be in slightly better shape 
than in R2 (but maybe I am wrong - I noticed some font ugly display 
problems)

Pekr r3 doesn't exist ... I know i'm a stubborn moron  ^^ that's 
my way to be 1st it's on R2 complete and full wrokking then i will 
adapt it to rebGUI then i will do REBOL IDE then in that time R3 
will be official released and i will do the port

since work is in progess and unstable it's hard to get serriously 
depending on it...

that's not that i don't like R3 or the new VID etc ... but what guaranty 
i have the actual R3/VID won't get the same destiny VID 3.4 got ?

pekr font ugly problem have been solved in a way and if font ugly 
issues are not of my consern you want to blame someone blame CArl 
since the time we say him that there is still bug in R2 and he doesn't 
 want to fix them ... in that matter you can see R3 as a way for 
carl to escape the pain of fixing  R2 countless bugs

font-fixed seems to not exists on MacOS X ... and since the whole 
positioning system is base on fixed-font that means no area-tc for 
mac OSX

You should be able to find a fixed-width font on Mac somewhere and 
specify that using  font/name: "your-fixed-font"

the actual situation is a pain R2 doesn't evolve and R3 is not stable 
and evolve so much that it's hard to base any serious developement 
on it yet .Where is the point if you have to restart your project 
from scratch every weeks because all changed

Shadwolf - I am not blaming anyone. Font ugliness has something in 
common with font hinting. Cyphre told me, that such code in AGG is 
licensed (or patented?), and that we will have to find some other 
way around. But you would have to ask Cyphre, I don't remember exactly 
what was the reason ...

as for rich-text - you don't have to use VID at all, just gobs. Besides 
that, VID 3.4 (Carl's VID, Gab's was VID 3.3) is the official one, 
and although we expect some further additions/changes, basic principles 
are in there and they will not imo change much ...

PEkr hum gtk+  lol

no i'm kidding around ...

Don't understand gtk+ joke .... (probably because I know little about 
gtk itself :-)

but having a VID 3.4 means we got a VID 3.0  a VID 3.2 a VID 3.3 
and those free where abandonned how can i be sure in the 6 month 
to come carl won't change again his mind

and since text editing is related to UTF-8  better to get all the 
things ended to not have to constantly have to redo part of the job

all previous VID's were Gabriele's implementations of Carl's/Cyphre's/Gabriele's 
discussions/specs. But for some reason Carl was not satisfied and 
decided to go with other design. And as it is Carl himself we are 
talking here, I would bet that the design will stay :-)

Pekr > you said we need to find a better way to handle fonts in AGG 
cause part of it was pattented (or OSE related) and i sugested GTK+ 
 with is os independent and GPL 2.0 (pango is a heavy but really 
complete way to handly richt text rendering )

btw - once we have plug-ins/dll back (integration methods being stronger 
hopefully), I wonder if anything prevents us from not using View 
at all, and linking Core to stuff like SDL, Qt?

but gtk+ is 10 time the  size of a rebol VM ...

:-)

maybe doing a server/client style project ... but even then we need 
 people to maintain that solution to fit the gtk+ cahnges through 
the time