AltME groups: search

R3 is a work in progress it's normal to not already do heavy things 
with it. But at same time not using it doesn't help to find the problems 
it has to solve them

It's a bug in the first of Carl's list of alpha testing priorities. 
We should be far beyond this level, but we're not.

Gee, how is money datatype really important? I NEVER used such obscure 
datatype even in R2. How is that a show-stopper for you?

Money as a datatype is useful as it is implemented as a form of BCD 
-- hence more digits of precision:
http://www.rebol.net/r3blogs/0094.html

Sure - it is a known thing, but I would not call it being a show 
stopper. We haven't had this feature for 13 years, so why should 
it be important right now? And if there is a bug, just claim your 
interest and it might get fixed.

Talking about that : http://www.rebol.net/cgi-bin/rambo.r?id=4363
This one was a show-stopper for me recently. Seeing such bug scared 
me about using money! datatype in R2. I had to rewrote several parts 
of a customer product using integer!-based fixed precision instead, 
just to be sure that amounts in the product would be correct.

John, some comments:

- Bug #60 is an error formatting bug, not a divide-by-zero bug. Low 
priority.

- Bug #115 is waiting for a decision. All waiting bugs are either 
waiting for a decision or for some other bug to get fxed. This particular 
bug is low-priority, because we have more important, lower-level 
things to worry about than another display bug.

- Bugs #250 and 576: The money! datatype has been completely rewritten, 
and currency hasn't been added to the new type yet. It is intended 
to have currency put back in it eventually, afaik. The math parts 
work though.

- Where's the CureCode ticket for that insert into issue! bug? This 
is the first I've heard of it. Submit a ticket if you think it's 
important.

- We haven't decided whether issue! will be a string type or a symbol 
type (I'm betting string), and it seems to have a few Unicode issues 
like the string! type does. The issue! type is low-priority compared 
to some other, more useful types, for now.

- I agree that bug #698 is high priority. Good catch - keep 'em coming.

R3 may be a little weird, becuase you can have mezzanine code that 
is lower-level than native code.

By the way, almost all of the map! bugs were found by me while writing 
a single mezzanine function.

Also that it's not possible to use binary as a key in map!

Oldes, #397 is high priority, and you need to add a ticket for the 
binary key bug.

Shadwolf, we had 3 releases over a two-day period last week - that's 
more like it :)

Sorry Brian.. it's already possible to use binary as a key in map! 
:)

And the only thing more important to code organization than modules 
is a good developer communications infrastructure. It has been a 
real boon to have the new chat and DevBase.

Gabriele, a lot of the development process *is* open. Check chat/DevBase 
for details.

Added a bug for the insert string! into issue! problem Geomol mentioned 
- it hadn't been reported. It is another Unicode display / MOLD bug 
- the data is fine and FORM and PICK work fine. Probably related 
to bug #640.

there is not lack of information, there is just a general ignorance 
to get to the information.

gee - what are you talking about now? Yes, there is Chat, which is 
more a unified replacement of some altme worlds and DevBase CVS, 
but - by info I also mean blogs, bugbase, detailed release notes, 
new docs with changelog, whole rebol.com R3 section, detailed month 
plan focus. I don't want to participate into this discussion anymore, 
as it is really rudiculous ....

it's like if every tv channels on a day would split the whole news 
and only give 2 information by channel to get the whole thing you 
have to watch them all

yeah that's why ppl ask and maybe get it wrong then on the explanation 
they can get a better idea on what's going on

I will go so far, that I even think that some part of the community 
became so ignorant, that making R3 fully open sourced would not change 
a bit of this situation. Some real work is needed, and ppl here complain 
that they don't have time to even scan sources of available info. 
Now tell me, how the same ppl are supposed to do any quality code 
for R3, even if it would be open-sourced? Once again - GUI is open-sourced, 
protocols are open-sourced, yet ppl don't even care to test or give 
a feedback.

Pekr easy to say we are bad since the code is closed and only teh 
elected ones can put a hand on it

yoru making my skills in question ? really ? well my head is not 
enough big to think i'm a all mighty guru that's for sure :P

plus you have to take in note motivation is it affortable to spend 
time in a no one cares and use language ? on extrem thinking you 
can go there too ...

as a matter of fact many people in french community who were really 
moved by rebol stopped about 1 year ago to appear why? most of them 
said they loose their faith in rebol

and i can reply how do you now and since it's not open then we won't 
ever know and as a matter of fact when a project is open source you 
have lot of dinamism in it  yeah some things even open-sourced never 
progress but some other widely extends

and submiting a bug with aving a hand on the source code is improvement 
of the information even if in the end that only CArl who solve the 
bug saying him  this doesn't work properly we expect that and in 
the source code we can see that issue and we propose to solve it 
like that what do you think that's in my opinion a better way to 
get dynamism in the community and even ppl skills enhancement  than 
only getting a black box where you can just say when i do that i 
expect that and that doesn't work

but we are not talking about that I was talking about getting inforamtion 
on the on work in progress if i don't go to 10  different infomation 
spots than I can't get a wide view about who does what when and how 
and the only thing left is to complain "that thing doesn't work" 
on altme  ^^

but still then instead of having a resume source of information we 
have a deeply detailed and separated source of information and the 
 wiki tends to resume the work but not getting anough large in the 
resume.

I read this whole discussion. I understand what Geomol is complaining 
about building and making it stable from bottom to top. That is a 
probably good eigeneering practice, but this is a little different. 
IMHO Carl and others don't just have to *code up* the R3 but they 
have to *design* the R3  (it's concrete implementation, it's core 
API, 1000s details) and there are a tons of small decisions to make 
all the time and you have to see and work on it from many angles 
so whole thing will come together well. IMHO

It's like making games.. if you are cloning another then you have 
a model that you just need to do as efectively and good as you can 
and add a few features and twists here and there. If you are developing 
an unique gameplay, you don't code it up.. you prototype .. work 
here and there because you learn what to do next as you do things

Imagine a client giving a taste to a programer and the programmer 
flee away don't get any news dor month and then comes back with oups 
sorry here is your program dear client ?  Do you think the client 
 will take that attitude as a serious matter ?

This aproach surely isn't good for clients that want the product.. 
to me R3 is a research project for now.. R2 is the product.  


But it should be good for community, because you mean you have some 
insight of development process, you can affect it with opinions and 
participating. Wasn't REBOLs biggest complaint always that is't so 
closed. Now you can see all in the open how it's to make it. :)

Ok so now I think this point is been integrated by Carl but he started 
to build lot of information source broker for all teh needs of the 
current task  but as an outsider (yes unfortunatly I'm not in god's 
Secrets...)  it's hard to retrieve relevant information and knows 
what's going on .. that's not to be hard with anyone that's just 
a matter of fact and to have discussed that matter a countless time 
with many ppl in the community (lame outsiders as Pekr would say) 
I'm not the only one feeling that way

Janko the thing is teh people working on R2 are the same as the ones 
working on R3 so it comes to why fixing R2 since it's already dead 
and we are cooking a better thing it's better to focus on R3 since 
we are only a couple of guys passionnate with it

I understand you, I am not frustrated about R3 because I don't wait 
for it ... R2 is the product for me , I at this time only care for 
what I can with some certanty use in production and R2 has tons of 
libs, examples, cheyenne .. and as a language it's also more interesting 
and hides more stuff that I can comprehend so exploring what can 
be done with R2 is still exciting to me.

R3 doesn't bore me that's just a bad image sent to the word in the 
way it's done that's all. Look before even doing a single thing a 
big company like apple or microsoft start by promoting it giving 
the  features the roadmap the developpers inside point of view etc 
...

on teh r3 project we really feel that's is like a river the flow 
goes and you never see from where it commes and where it goes

So then knowing if a bug you find in R3 lastest release is already 
known or already solved is hard

yes, I understand that... I was waiting for R3 for years ( I just 
used rebol for smaller stuff here and there at that time ) and frankly 
I was sure R3 is vaporware.. it's a 1 man design process with benefits 
of it and also limitations

and you see some things not advancing for long time like unicode 
support (i'm not even sure that will be a profit to r3 well as i'm 
an idiot i'm certainly wrong on this point)

MS would do it other way.. but they would still need one guy with 
some crazy ideas that actually work and produce something special.. 
and even as big as they are they don't have it.. C# is a copy of 
Java, F# is a copy of OCaml ..

denefits would be since there is only one guy with the vision of 
what he wants and how he wants it the creation process will go smoothly 
but the thing is that since the past years the R3 is started many 
 ideas in R3 have been changed a lot of time (like VID)  abd bothing 
ensure us that in the month comming another idea will pop and so 
one making R3 a never ended project

I mean it's normal for a program to evolve but it''s not normal to 
be stuck in the first stable output

you can always feel a program is not ended but can a program handle 
all the functionalities of now in day computer.

plus no one knows if in the 2 years to come Carl would have a totally 
different feeling on what he wants rebol to do

(well maybe he spent whole talk, because I stopped watching at 20min... 
it was boring a little)

ok, to get the protocol in a few steps: start r3, type "chat". type 
"more 3365"

just give a nick and a pass

*off-line* guest:>> more 3365
--- Note: select a message topic

I created a user and logined now.. it says it's fetching messages

you can't. you need a higher ranked person to do that. I'll see what 
can be done.

I was going to paste the code to Janko in a private message but AltME 
can't handle Mac line endings. Perhaps somebody running on Winodws 
could post it to him.

Has anybody tried running a server port on Linux?

just one more question ... does the async networking on R3 work as 
it was shown on wiki for a while (the old one had examples)

I think ports have not changed for over a year, so examples and docs 
should be up to date.

Henrik. Try re-starting Rebol and then use chat. I have found that 
chat only segfaults once a certain amount of memory has been used.

I'm not expecting a usable R3 for another year or more.  I am really 
busy workting my project in R2, as i suspect are many others.

Maybe once we have a usuable GUI wrapped around dev chat it might 
be easier to follow what is going on ... but it's a bit of a black 
box to me now.

Henrik. I only get the seg fault if I use a lot of memory or try 
to use a scheme before running chat.

I get a crash immediately. Do you start it from terminal or Finder?

hmm. Instruments runs R3, but doesn't open a console, so it isn't 
interactive.

Attaching Instruments to a running R3 works. But it shows no leaks 
when entering Chat.

PeterWood, I get a different crash from what you had before now. 
"N" when you are guest, right after starting chat.

Will test in a minute. I haven't found out how to return to Guest 
state again.

ok i just remember i recieve a mail with the damn password

shadwolf: <ok so hash! is gone perfect no one used it anyway>

A quick search on REBOL.org shows 25 scripts using hash! and/or to-hash

That's not many. But it is not zero. And it is not perfect for those 
with applications that depend on those scripts.

Clearlt, retaining hash! is not a priority for RT, and that argument 
has been and gone.

It is not a decision I am happy with .... which indicates my priorities 
are not completely aligned with RT's. That puts me in the same position 
as most REBOL developers :-(

I've been using hash! for a bit, but there are too few advantages 
for it to be directly useful. The main advantage is supposed to be 
speed, but usually when you need to do real work with a hash! you 
need to convert it to a block!, which slows the whole script down 
more than if you just used block! correctly from the beginning.

shadwolf, it could be, because it's not well documented. I didn't 
learn of its existance until after a few years of REBOL usage.

Henrik it could be because it's not doing what ppl used to code their 
own hash table in C expects from a hash! table  any way it's GONE 
farewell :P

what you want a farewell party for hash! with champaign and etc.. 
?

but my understanding is that hash functions different than hashtables 
or dictionaries in other languages? and map will work that way.. 
or did you need the specific way how hash worked? If I used hash 
I used in as a hashtable (because I wasn't aware of the difference) 
and I could have gotten nasty errors because of it

earing from the few in teh God's secret map! is much better even 
if it's not fully done. I'm a morron so the only thing left to me 
is to believe them  ^^

I used hash! to build a long list of de-duplicated words. It was 
by far the fastest way in R2.


I was pleasantly surprised when I found that using map! and storing 
every associated value as #[none] was quicker in R3 than hash! in 
R2. It just seems wrong to be wasting all that memory storing all 
those unnecessary ones.

hmm... here's a fun one: decompress read http://www.rebol.com/r3/chat.r

Gobbles up memory and just hangs.

I guess this is due to the new method for COMPRESS to allocate memory 
prior to decompressing, but if that is possible, then it's simple 
to DoS a rebol server that relies on compressed input, just by sending 
a malformed binary.

Pekr, I remember Carl mentioning this a long time ago: DECOMPRESS 
reads first how long the item to decompress is, then allocates memory 
and then attempts decompression, so it's a deliberate design choice 
for memory limited embedded devices.

So if you have a 2 kb compressed binary but the header of that binary 
states that its 10 GB in size, you will get that error.

Wasn't map supposed to be a hash! replacement plus/minus few differences 
in behaviour?

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

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

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

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! ?

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

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

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

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

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

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

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

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 )

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