World: r3wp

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.

and the problem is ???

is there a problem? He's just sleeping now, so he hasn't received 
the solutions yet.

I would prefer GUI version. We should also create priority list - 
what should happen after the plugins are released? Release first 
host code, examples? Then what? Move onto parse? Unicode? (still 
things like collation, sorting not supported)? GUI?

R3 could be kind of successfull on devices like my 4 days old HTC 
TouchPro2 :-) There is e.g. special GUI version for YouTube, wrapping 
the service, hence no need to go via browser. I think that we could 
wrap some such services, especially the ones having APIs, as Google 
ones. That would be good showcase for ReBrowser :-)

My percent! preference is the same as for other decimal values: always 
be correct. :-)


In that regard, what are the chances, and ramifications, of percent! 
using the new bignum internals that money! uses? 

Please don't make it use scientific (E) notation.

scientific notation should be banned !   ;-)

And therefore should Planck's constant always be written as:
0.000000000000000000000000000000000662606896
;-)

maybe it makes you respect the number more :-)

Please don't make it use scientific (E) notation.
 - so, what do you want to get from:
10% + 10% + 10% - 30%

(in the previous version the expression caused a mold error)

(exactly since the E notation was banned)

aha, you want to use the money! datatype! yes, that is an alternative, 
but does not ban the E notation anyway

I don't want to ban E notation entirely, but using it should be by 
choice if at all possible.


It's always struck me as odd that anyone would *ever* choose FP, 
assuming they want correct results. :-)

its a question of speed...

display and value are two different things.  I understand the need 
for scientific notation to represent the value, only that there are 
no easy ways within core to deal and show the result below at a given 
decimal point without having to convert it to a string and always 
check the scientific notation in uneeded cases.

how much time to get a gui in rebol3 linux and other ?