World: r3wp

I started a deep deep thinking process wich is a heavy task for an 
idiot biain of mine concerning the futur of viva-rebol and where 
i want to lead it.


If you have a little interest for what i'm doing actually you know 
that i'm actually working  on 2 projects viva-rebol and rekini. I'm 
interrested in transforming viva-rebol into a real time collaborative 
project. manager/editor something like wave but done in rebol to 
create rebol application.


The idea that comes to my brain is to mix IRC and vivarebol. IRC 
would be the supplier for sharing real time documents content information 
and viva-rebol will be at the same time manager and the renderer 
that will catalise the informations collected by irc.


Why irc?  first because they have lot of control feature wich can 
allow anyone to join and see an onShared-creation docuiment  or script 
and only look at it without active participation. That can allow 
a hierachy system with master, co-writer and only viewer. and the 
allow the master to select who participate or not to the création.


We saw with area-tc that rebol and VID and the dialect concept was 
really feat to handle uncomon text handling  at light speed so the 
appears clear for me that this is the next step to go.


Some people will say to me "but it's more important to have an advanced 
rich text editor tool"  which i answer that boring to do and in the 
result the gain in notority for rebol is close to 0. So instead of 
 clonning MS-Word using VID I prefere move to the next step wich 
I hope will lead us to make people see all the potential of rebol.


It took me looooooooooong time (6 years in fact) to see how to merge 
all the interresting part of rebol to make a big project wich we 
could be all be proud of and show all the interesting part of rebol.


Our comminuty is small and working together to make advance the projects 
is obvious if we want our project to be recognised in some way. If 
we all work on our sides on our own project achieving a high quality 
for those projects is hard.  So externally we only show to the world 
project that looks more like teasers than completed project and that 
not a good thing for rebol promotion. We can say all we want about 
the way rebol is done by Carl but us as community which goal is to 
spread rebol world wide we have a part of reponsability in that too.

I think proposing a collaborative real time tool for making rebol 
script is a good idea as a leading project to make every one acquiere 
or show high level skills. That's in my opinion more productive than 
having Gurus explaining to stupid morons like me things during weeks 
with no concrete result to it.  Sooooooooooo I propose to KEEP IT 
SIMPLE. Instead of explaining me the solution take half of the time 
you normally use to answer me to edit my script make the changes 
and then ofcourse we can have a nice chat on why you used that and 
not this and that will make my level progress a lot. And most important 
of all the problem and my project will be solved and working.

ofcourse if that tool allow 10  personne to build from white page 
a rebol script that can allow them to write a documentation allowing 
them to see how are feeled each part of the documents by the contributors 
and make comment on those parts on real time.

this project that will start as a commuty oriented project can then 
be retaken as it by compagnies to speed the way they work. and not 
only for rebol scripting porpose.

another motivation for basing the data exchange part on irc is that 
their is a lot of irc server all around and using them is really 
easy stuff. That's in my opinion faster than making a web oriented 
tools then convince the hoster to allow us to install rebol on his 
web server etc...

but if you want a persistant extension of that making an irc bot 
that collect all the project worked with the viva-rebol online feature 
and making the bot publish them on web that's easy to do.

of course it's totally up to you.. but I try to make bigger projects 
in *finalizable* steps. My advice is to first release at least simple 
but usable IDE and when you have that nailed transform it into a 
realtime editing thing :) . There is still a lot of problems to solve 
when you try to finalize an app and it also teaches you a lot about 
the product you are making. Moving target higher and higher is a 
nice way of not releasing anything at the end.

janko have you tryied viva-rebol ?

no where can I find it?

Viva-Rebol is here:
http://my-trac.assembla.com/shadwolforge/browser/viva-rebol.r

ah, reduce/into and compose/into implemented including chaining ....

June plan blog: http://www.rebol.com/article/0409.html

http://twitter.com/rebol3

Added to my Google Reader :)

I think R3 chat would be better suited for this. It would theoretically 
be possible to create twitter like feeds.

Carl just might agree. :-)

Yeah, after we get the GUI so we can bettter distinguish the twitter-like 
feeds from the conversations.

Carl was the one who was complaining about the status updates overwhelming 
the chat in the first place.

file notiications no longer show up in new messages. I think it's 
possible to filter messages from specific headings out, so you specifically 
have to visit that heading to read the messages.

perhaps it would be possible some day to apply specific attributes 
to a heading.

hm.... i don't think so, all the remaining messages are sent after 
each sync in the CHAT

you think it would be too many messages to get in the background?

i don't think Carl has changed this design drawback

The chat protocoll doesn't know how to request a specific message 
from the server, all is loaded in local and the requests are performed 
in your client memory

files are the exceptions, but the tag message for a file (the link) 
is loaded in your local file, even if you don't download it

The R3 chat protocol (as it is now) is not suited for real chatting 
with a massive exchange of short messages between users or specific 
channel.
Because each time you sync, all is loaded in local.

Same drawback as Altme

So more there will be traffic and users, more it will be slow and 
like with Altme, there will be a need to clear the database after 
a while

twitter is one-way, AFAIK. no chatting.

Another drawabck, if an existing user launch the chat from another 
one place (another directory, disk, or computer), the all the database 
is loaded again in local

freaking behavior, like altme

Yes But i'm afraid that twitter will generate a massive flow of messages 
after a while.
And even if you dont read them, you download them after each sync

Only if they are mirrored to chat, which they currently aren't (thankfully).

Massive

 is relative. A sync of 4500 messages from a scratch takes roughly 
 10 seconds here. I don't think it poses a big problem.

Well it's a problem for my poor connection

You do it once. After that, do you expect to receive thousands of 
messages per sync?

Twitter allows for "direct messages" which are not seen by everyone. 
Twitter can send messages to your mobile at no cost in the UK

loading http://twitter.com/rebol3here is a 14 kb webpage for 8 messages, 
excluding images, so it's probably 20-30 kb each time you want to 
read it. With the information amount we want, R3 Chat can probably 
deliver over 200 times more messages in the same bandwidth, assuming 
that each message is < 140 chars. And also R3 chat only retrieves 
them once. After that, they're local. Twitter loses. :-)

I guess someone needs to make a REBOL client for Twitter.

steeve, local caching is not a drawback, its a feature... it prevents 
the client from having to check all messages EVERY time it starts 
instead of just once.  there should be more parameters though, I 
agree, giving a time frame would be good, so that it knows to forget 
old messages you don't care about, for example.

Better support for background processing would be nice too.

Not really a problem for R3 chat, but a big problem for AltME.

; Shorter Rebol3 Twitter client:

do http://www.ross-gill.com/r/altxml.r

r3tweets: load-xml/dom http://twitter.com/statuses/user_timeline/45953552.rss
                     
foreach tweet r3tweets/get-by-tag <item> [
	print ""
	print tweet/get <pubDate>
	print tweet/get <title>
]

That is 'Rebol3 Twitter', not 'Rebol3 client'...

Hi all. A percent! datatype question. What are your preferences with 
respect to the full IEEE754 64-bit range?


1) Current state: the whole range is used for percent, except for 
the fact, that LOAD and MOLD cause error when encountering results 
such as: 10% + 10% + 10% - 30% (not exactly zero)

2) Use the complete range and correct both LOAD and MOLD to be able 
to show any value from the range - this means, that the E notation, 
like 1E-15%, or 1E20% may be needed.

3) Change the %arithmetic limiting it to a subrange of IEEE754 (may 
be complicated - every operation needs bound checking and slow)

What I hated about R2 was EEE format usage, especially when you needed 
to mold/print into something user-friendly. If R3 has some form/format 
function, which will handle that, then I don't mind using IEEE notation 
in console. I am not able to answer 1) - would it make any possible 
harm to our code, its reflectivity or ability to save/load molded 
values and getting exactly the same results?

LOAD MOLD - Carl took care of that (seen twitter?)

heh ... must be total coincidence ... I showed how easy it was to 
post to twitter from Rebol, and now Carl is tweeting!  But oddly, 
not from Rebol.

he is asking for an R3 twitter client though.